Why Most Product Planning Is Bad and What to Do About It

Our Quarterly PI planning is nightmare but Sales wants to sell the backlog so fighting is different business units fighting over which items should be done and how fast they are done.

It's generally employees meta optimizing for themselves instead of larger business and business is too big for CEO to figure out. Railways career page says they are a team of 27 so CEO/Founder/Whoever has vision in their head and keep steering everyone towards that vision.

However, as Ops type, looks like could be interesting job. Digs further

I have fixed the sentence fragment and connected the two thoughts together. Thank you for keeping me honest.

But you're working in a pretty well known area. You don't really need planning for all 1000ish people as you could take this well known area and divide it into pieces that are largely independent. These pieces are either just table stakes where you need to be good enough but not innovate, or they're part of your vision for how to differentiate from other PaaS companies. You can budget accordingly and let these pieces do their own planning with their importance for the overall vision as context. (If you don't have a vision, your company is probably a mistake. Why are you even there?)

If there's an area where you don't need to innovate much, but you need to catch up, they might actually do a 3 month plan. If there's an area vital for your vision, they are probably trying new things, learning and re-targeting. Three months is far too long to plan for them on a tactical level, and probably too short to actually deliver on the vision.

You can certainly have a quarterly checkup or something to see that all parts are working from an upper management level, but the useful planning horizon varies by problem area, and they don't really need to plan in the same way.

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.

I usually tell people they should try to plan based on what exists. Occasionally it's not possible and two or more teams need to cooperate, but planning 15 teams with lots of interconnections about hypothetical things is too hard and brittle. If you need it, your teams are probably split in the wrong way.

X-team initiatives do need planning and coordination sometimes, but if you have a lot of x-team initiatives, your teams are probably set up wrong. If you fix that you can plan less.

If this is a process to decide what to commit to start working on, not to finish, then that makes sense, and I congratulate you on having an environment that acknowledges and accepts the impossibility of planning results rather than planning activities.

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.

> So then you get these version numbers, even with decimals: version 2.6 or 2.7. That nonsense. While version 1 should have been the finished product.

E.W. Dijkstra

Translated from the original Dutch [1] [2].

Dijkstra was convinced that programming was a formal application of mathematics. If the program has a bug, the math is wrong. If the program is missing a feature, the math is incomplete.

Personally, I feel that building software like a bridge is the better path. You don't want the bridge patched with new supports and "stability improvements" every time another fatal design flaw is discovered any more than you want to update your OS and system libraries every time a new CVE is announced. These scenarios are both disruptive and costly. But somehow, we have been collectively tricked into accepting it as an unchangeable fact of software.

The advantage of software is that I can "replace the whole bridge" with a completely different design if I wish. Not merely patching an existing bridge in place, with whatever poor aesthetics and integrity problems that leaves behind.

[1] https://www.cs.utexas.edu/~EWD/video-audio/NoorderlichtVideo...

[2] https://youtu.be/-Uae9_pgZzE?si=twwh7k7cPKRB2gvJ&t=50

I think software is a material, like steel. And like steel, there are properties of software you can take advantage of to build in different ways. For example, its ability to be turing-incomplete, or stateless/immutable, formally verified, interpreted vs compiled, composeable vs fully integrated, distributed vs isolated, etc. You can use the material many different ways, thus building a very different product.

It's also a material like a gas, in that it fills any container it's stored in. Or perhaps a flame, as it consumes all resources you give it? Or a clay, as it's easy to work, but needs to be specially treated for it to be stable long-term... Anyway, these properties of the material need to be better understood, so builders can understand the right ways to use it. If you are building a bridge, I sure as heck hope you're using the right methods.

The idea is that there are numerous pieces of work that your team will do which take longer than 2 weeks and you’re better off planning on a longer window so that you can find the best way to execute with clearer scope. This is the approach of all of the longer timelines and it’s much more effective in my experience.

The 6 week approach advocated by ShapeUp tries to find a balance from years of trial and error that balances “enough time” with “short enough that there’s still a sense of urgency”.

The other hard rule for this system is one that I’m a huge believer in. Namely, “if you are doing something that’s too big for 2-3 people to ship something in 6 weeks it’s too big and you need to trim it.”

It doesn’t say “complete” it says “ship something”. Thats key. There will always be work that takes more than 6 weeks, but you should always be able to find a way to slice it into smaller pieces that can be shipped. There are subtle things happening under the hood of this simple dynamic that force a lot of good practices from everyone involved too.