kschrader

Also stuck in this endless loop.

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.

Here for questions/comments if anyone has them.

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.

For reference: https://www.pivotaltracker.com/blog/2024-03-12-subscriptions...

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.

Depends on the size of the organization using it.

It is until you hit the wall on it and then you end up with a lot of tough tradeoffs.

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.)

Maybe it's just me, but other than ad-free articles what value does Blue bring to the table? (Just an edit button?)

Anyone here paying for it and feel like they're getting their money worth?

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).

Ticket update overhead sucks.

[1] https://clubhouse.zendesk.com/hc/en-us/articles/207540323-Us...

"Something along the line of themes" is coming soon...

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.

To be fair, they did say "no" to this. (After 11 years. :-) )

Agreed. It feels like Atlasssian never met a feature request that they didn't say "no" to.

Unfortunately, most of the tools out there don't scale well, so most teams reach the point where Jira is the only reasonable choice.

(Full disclosure, building https://clubhouse.io address this problem.)

Just for comparison purposes, once a large portion of your housing is safety deposit boxes here's the sort of thing you can get for $300K: http://streeteasy.com/building/5-tudor-city-place-new_york/3...

275 sq. ft. with "a half refrigerator, 2 built-in electric burners, and a microwave oven"

It literally says in the article that Hastings fired the Chief Talent Officer that came up with the "Would you hire them again today?" litmus test that they use because she no longer passed it.

Is the install base for high-end PCs (of the level needed to push an Oculus) really larger?

They've sold 36 million PS4s.

An Oculus needs a Nvidia GTX 970 or better graphics card (which goes for $300+ on it's own). I highly doubt that 36 million+ people have purchased one of those (or would, especially on top of the $599 that it costs for the Rift itself).

We're focusing on teams of 3-150 developers right now.

We have some of the building blocks in place for bigger teams, but it's not a priority right now.

The software is built so that we can ship an on-prem version at some point in the future, but we don't have the processes in place yet to make that a reality.

Nothing planned yet, but if there's enough interest we'll consider it.

It's on the list of things to do at some point soon.

Here's a blog post that one of our users wrote a few months ago that covers some of the same ground: https://medium.com/humans-in-space/clubhouse-is-the-best-pro...

We tried to price things fairly but still make enough to grow and invest in the what we're building.

PT uses tiered pricing, so if you have 16 people we're only $10 more a month than PT and at 26 people we're $40 less expensive each month.

We tried to use rather generic agile terms.

Here's a reference to most of the same concepts on the Jira site, for instance: https://www.atlassian.com/agile/delivery-vehicles/

(I've worked with Pivotal on projects in the past and I worked at Thoughtworks for a while, so we're definitely using language that should be familiar to users that are familiar with the flavor of "agile" promoted by those companies.)

It's a constraint imposed, by design, so that you view progress easily across projects. (i.e. view the progress of the frontend, backend, and UI team against a common epic)

Some of our users have extra steps in their workflow (for example, "waiting for app store review") that some of the project teams hide in their workspace (each column in the workflow can be hidden by an individual user).

In the future we might support different "departments" within an organization to allow for multiple ways of working, but it's not at the top of the list of things to do currently.

We don't currently have any official integrations with external issue trackers.

We do have a full API though (https://clubhouse.io/api/) so it probably wouldn't take much effort to build something for your issue tracker of choice, which some of our users have already done.