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.
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.
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.)
We do a lot of work at Clubhouse to keep things fast.
We have alerts set up that fire if the p50 or p95 of certain actions spike and we treat it as a bug if things are headed in the wrong direction.
We still see a lot of random cases of things being slower though (shakes fist at random browser plugin upgrades).
It's a hard problems, but if you don't design (and monitor) for this from the beginning things are going to slow down over time as you scale to hundreds of thousands of users.
Just to clarify, we think a lot about product managers, but when there's a tug-of-war between making life easier for developers vs making life easy for PMs we lean towards the former.
One of the lenses that we look at things through when making product decisions is making it hard to do things that end up feeling like paper cuts for developers all day long.
I've always seen Jira as the "manager's tool" and we're trying to make Clubhouse the "developer's tool."
It's a simple decision that I think (and I'm obviously biased) has had some profound effects on the way we've built Clubhouse.
I'd argue that we're stretching a bit with the word "need" here. Are we still at the point where every software development team has to come up with their own special process?
I feel like, as an industry, we should be moving beyond that at some point.
One thing that we've built[1] is a way to hook a Branch to a story (by including the story ID in the branch name, which also starts it) which causes all of the commits on the branch to feed into the ticket and allows you to use Pull Requests and Merges to change the state (i.e. "Open Pull Request -> Move to Ready for Review).
Perhaps you confused "it feels like" (implying that it feels bloated with many esoteric and/or generally useless features) with the statement "there's literally never been a feature that they've said no to" which is something else entirely and what you seem to be disproving here.