building a collaborative product management tool, called co-op-os. the core idea is to standardize and codify a lot of the ceremonies teams run to build alignment around problems, decide on solutions, and actually ship features that benefit customers. the most effective teams i've worked on didn't have one person building out a master sprint plan, but had a bunch of individual contributors coming up with ideas for optimizing a goal, getting another smart person to sign off, then building it. this is an attempt to standardize that more distributed planning/operating model in a scalable way.
never have i ever been involved with a _successful_ software project where product decisions were made entirely by product people and handed off to design/eng.
in my limited experience, good product builders exploit leverage points that in order to solve customer problems / test assumptions quickly. for example, usually the product people don't know how flow X is really easy to restructure like Y and solve the same problem. kind of related, but pushing all the speccing responsibility to product is also kind of boring for me as an IC.
blaming the user does not feel like a winning strategy, idk. totally agree that it's a bad tool.
a previous team i was on used github issues with a labeling system then switched to jira when we wanted to "get serious". my est is that we had a 50% decrease in issue quality and it shifted from 50% -> 90% of issues written by PMs and managers vs ICs who had a finer grained understanding of high leverage (impact/effort) tasks. i really do blame 1) the shittyness (er... "complexity", er... "power") of the UI and 2) the strict sprint-gaming behavior it encourages. i love a strong PM/EM for directing the team towards business value, but less so for enumerating and prioritizing the micro-tactics to get there.
edit/disclaimer: i admit i'm super biased, but i've thought about this a lot working on a competitor of sorts.
ended with a cliffhanger! OP eloquently picked apart the predominant system without a clear alternative :)
mostly agree with the premise though, and I'll add that "sprint" is insane nomenclature for something that you do continuously week-in and week out.
my question for the author (and ya'll) is how to reconcile the time-waste of estimating with the fact that you do indeed need some estimate of how long something is going to take in order to decide whether you should prioritize doing it (we like RICE [0]). as the designer on a startup team, i'm not going to push for designing / building some crazy VR UI no matter how much we hear a customer asking for it, but i'll definitely design some 3d button transform hover states or other small finesse if the front-end eng says it's easy to implement. i'm sure i can think of a less extreme example, but not today.
this is a rad concept, thanks for sharing. sad that i can't play with it on my mac. from the screenshots, it definitely needs some design love, but it’s an interesting concept that really resonates with me.
i know it's too early, but do you have thoughts on monetizing it? i wonder if you could do something like pioneer [0] and broker funding rounds for the really promising ones — looks like you have some background there.
i’m working on designing something that is a bit like this, but for guiding the product building part [1]. it kind of papers over this idea validation step via a “wisdom of the crowd” voting system. do you see startizer only being focused on the initial idea validation part, or do you want teams to continue using it to iterate and build over time?
yep, if you want your product to succeed, it has to be a really good product... why do people think this article is so great? isn't what altman says common sense?
I think you're missing the point. How long does it take for that fix to be downloaded? Tons of users will never see it. Tons of users will continue to use the version with the vulnerability.
feedback more than welcome!
https://www.co-op-os.com/