One other note: We've seen teams where people are now using Korey as the main surface to their work tracking tool.
They show up in the morning and say "what was I working on yesterday?" "what else do we have to do in this sprint?" "Assign task XYZ to Devin.ai and put Story ABC into the started state and assign it to me"
It's been unexpected and surprising to me how fast the tools that we've used for years have become tools that are only looked at occasionally for some of the teams that are really leaning in here.
I'm not 100% clear on what the scope of ChatPRD is at this point (beyond PRDs) but Korey has a fleet of specialized subagents running underneath for everything from status updates to writing specs to breaking them down into subtasks to understanding how much work everyone on your team is doing and suggesting who the right people for the right jobs are (or agents for the job).
Each subagent is tied to and evaluated against different models (mostly Claude currently), so we can keep improving and adding to them independently.
We're also team centric by default, so if you want to see how someone on your team worked through coming up with a spec you can always see all of the work behind it. We're working on a testing and training framework that would apply your standards company-wide (coming soon).
Finally, we bill on interactions, so it's easy to try out and if you and your team are finding it useful and getting value from it then you pay us, if you don't then you don't. Hopefully this best aligns us to keep improving things and making it better for everyone, instead of just billing you by the seat, regardless of how much people use it.
Interesting! That makes a lot of sense to me -- and I could see how Korey could get better over time at interacting with other agents (e.g., with Devin to actually fix a bug).
Hi all, we started an experiment a few months ago to see if we could build an actual useful PM agent for software teams, and I think that we've come up with something pretty cool. Korey can take your ideas, flesh them out, and then break them down into tasks that you (or your AI) can build.
We estimate that it conservatively saved us about 100 hours of alignment in April alone, and it's getting better all of the time.
The Anthropic models are running underneath everything (Claude Code, Windsurf, Cursor, etc). Whenever someone is using MCP they (in the generalized case, until now) ultimately end up using Anthropic as their LLM and Anthropic gets paid whenever someone does that.
Having spent 7 years now building https://www.shortcut.com/ it's very clear to me that at a certain point in the life-cycle of many organizations a bunch of people get hired who can only "think in Jira" and the vast majority of feature requests are attempts to get us to add whatever feature(s) they love using.
Conversations about why it's bad for developers or product managers or attempts to show them how to get the same value in another way often fall on deaf ears (or don't happen at all) because it's the only way that they know how to work.
One of the key indicators that this is happening is when people start saying things like "this can't do Agile because it doesn't have PET_FEATURE"
Jira isn't just software, it's a way of working that's become the de facto standard, and it's hard to get out of that box for a lot of people.
For what it's worth, thank you for fighting this fight. Shortcut has been a fantastic tool for us as a direct result of it doing things differently and more naturally. Please don't change that!
As soon as we add a new feature to Shortcut people inevitably use it in a way that's complex and unexpected and that causes a large portion of the team to hate it. It's a very hard dance to do.
One of the big problems here is that there's no agreed upon mental model for how people think about the pieces fitting together (and I don't think that we could come up with one that would work for everyone).
Even if people do have the same model then the terms are often different, depending on how you learned to do things. (Example: What is the "correct" number of levels of tasks -> subtasks and what should each layer be called, i.e "Epics -> Stories -> Tasks")
We've been building out Shortcut (https://shortcut.com/) for several years now it's not uncommon for new leadership (new VP of Eng or VP of Product) to show up in a large organization (100+ people in eng and product) and decide that whatever problems the org is having can be solved by moving to Jira and forcing everyone into a new mental model around how they're building things.
(Side note: We're tracking the rate of success of people who make this decision and how long they last in the org, and it's [perhaps unsurprisingly] not great.)
