Sounds Like you rediscovered the “opportunity solution tree” (Teresa Torres) and were skipping a crucial step in product management / UX which is product discovery.
I would suggest not to generalize your learnings by saying “why most product planning is bad…” and rather use a more humble title “why our product planning was bad and what we did about it”.
Why most product planning is bad and what to do about it
21–30 of 49 posts
Re: Why most product planning is bad and what to do about it
#22Am I getting it wrong? It sounds like they're still doing quarterly planning just with a different ritual? I had hoped they'd realise quarterly planning is a bad premise and asked themselves why they do it. If you have a mature product where you add incremental features, you don't need that plan because it's just an arbitrary block of pretty fungible work. If you're still looking for product market fit, that three mo…
Hello there! Author there, and surprised/delighted with the response. I don't think we had the issue with the cadence, the quarter is arbitrary, but we think it gives us the ability to just go heads down to focus. With that said, one thing we did and I don't why we did it was that we would "re-justify" why we would want to work on something every three months which isn't great. There is a world where if we had more e…
There is no world where you have more people than problems because the more people you hire the more problems they discover.
Re: Why most product planning is bad and what to do about it
#23Am I getting it wrong? It sounds like they're still doing quarterly planning just with a different ritual? I had hoped they'd realise quarterly planning is a bad premise and asked themselves why they do it. If you have a mature product where you add incremental features, you don't need that plan because it's just an arbitrary block of pretty fungible work. If you're still looking for product market fit, that three mo…
Hello there! Author there, and surprised/delighted with the response. I don't think we had the issue with the cadence, the quarter is arbitrary, but we think it gives us the ability to just go heads down to focus. With that said, one thing we did and I don't why we did it was that we would "re-justify" why we would want to work on something every three months which isn't great. There is a world where if we had more e…
> There is a world where if we had more eng. resources we could have more people than problems and we could take stuff on board as it arrives
I don't think this is a realistic world. The cavitation surface area that spawns new bubbles of unvetted fresh ideas grows as things are added. Adding eng resources to get more done makes it grow faster and I don't think there is ever such a thing as catching up.
tl;dr - deciding what to build (and what it looks like in detail) will always be a critical and fundamental function of product teams.
Re: Why most product planning is bad and what to do about it
#24Am I getting it wrong? It sounds like they're still doing quarterly planning just with a different ritual? I had hoped they'd realise quarterly planning is a bad premise and asked themselves why they do it. If you have a mature product where you add incremental features, you don't need that plan because it's just an arbitrary block of pretty fungible work. If you're still looking for product market fit, that three mo…
I think quarterly is used as a heartbeat across many teams. If you know your 15 adjacent teams are also quarter planning you can start asking for commitments. It makes things easier to figure out for higher ups too I imagine (never been a higher up though)
Why not 6 weeks? Not sure. Gut feeling I like 3 months. Maybe 6 week sprints are good.
Re: Why most product planning is bad and what to do about it
#25Earlier quoted context omitted.
Hello there! Author there, and surprised/delighted with the response. I don't think we had the issue with the cadence, the quarter is arbitrary, but we think it gives us the ability to just go heads down to focus. With that said, one thing we did and I don't why we did it was that we would "re-justify" why we would want to work on something every three months which isn't great. There is a world where if we had more e…
There is no world where you have more people than problems because the more people you hire the more problems they discover.
Or create.
Re: Why most product planning is bad and what to do about it
#26Re: Why most product planning is bad and what to do about it
#27> For most of my friends and colleagues at mature software companies, (randos at a company with a lot of money) > there are usually three ways for an item of work to get put on the board (we assume that everyone should always do work in the same basic ways and there's no reason to change the way you work other than personal preference) > Thats not to say that every company is a disorganized mess or a bureaucratic hel…
Real world example of:
Patient: Doc, it hurts when I do this.
Doctor: Then stop doing that.Re: Why most product planning is bad and what to do about it
#28The real answer is that the methodology really doesn't matter as long as you have clearly defined problems to solve, know that solving those problems would be lucrative, and the knowledge gaps across teams aren't too big.
Because we live in the real world full of people who are allergic to work that requires deeper and more tangible skills than "management", we must settle for some kind of methodology.
Re: Why most product planning is bad and what to do about it
#29I must have missed something, because this seems to say you do capacity and headcount planning and publicly commit to the work before you know how to solve the problem ? This seems like the “draw the rest of the owl” part of this process…
I am more than happy to add color here, I am sorry, I try my best to write everything but my editor cuts as much as I add. We also tend to hire really autonomous engineers who tend to like just going off on their own to try to solve the issue. There have been a few times where we would commit to the problem, assign a DRI, and then find out midway that... no we have to hire/consult our way out of the issue. I think th…
This is interesting to me, too! My team is in the midst of opening new reqs. A leader wants to hire based on skillset. The team wants to hire based on upcoming work. We had a decent employee churn recently because the work wasn’t what they thought they were hired for.
I can see both sides. We don’t have work planned more than a quarter out (a good thing IMO). Generalist SWEs make a good fit. But we think we need someone specialized in AI/ML. Unclear to me if that’s the case… and how to plan for it if we don’t want to explore concrete features we _might_ build.
Re: Why most product planning is bad and what to do about it
#30>> When Platform marks "Multi-mount volumes" as P1 and Product marks "HA DBs" as P1
Hilarious how closely aligned product and engineering are here. There must be essentially no delta in backgrounds at all. Might as well just merge the functions and have engineers talk to customers (who would be developers as well presumably) from time to time.