Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why most product planning is bad and what to do about it

blog.railway.com

Post reply on HN
Print view View original

31–40 of 49 posts

Re: Why most product planning is bad and what to do about it

#31

Post by goalieca »

procaryote wrote: post #5

Am 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 have a spicy take! OKRs every quarter don’t keep you focused on the prize, they keep you focused on your own performance for whatever the industry equivalent of publish or perish is called these days.

Re: Why most product planning is bad and what to do about it

#32

Post by wrs »

ndneighbor wrote: post #12
wrs wrote: post #9

I 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…

"Try to solve the issue" is the key phrase there. In my experience you're generally wrong about how long it will take to solve any nontrivial software problem, and that's exactly what's hard about results-based planning.

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.

Re: Why most product planning is bad and what to do about it

#34

Post by affidavid »

procaryote wrote: post #5

Am 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 believe that planning out 5 year vision, 2 year vision, and quarterly goals would be best, but it’s really difficult when the vision is just making more money and quarterly goals are either “I want you to develop a product it took another company 10 years to create but make it our idea and better” or it’s some boring feature or maintenance work.

I used to think we needed our company to explain their problems, so that we could fix them. I less and less believe this is true. You can’t define some things. Home Depot doesn’t sell pre-packaged solutions for every need. They just sell a bunch of stuff, and they have people you can talk with to order what you need and even drop it off or install it. That is what some people need- a selection of stuff and solution experts. And that’s why MCP sounds so attractive; it’s a bunch of tools, prompts, and resources- a type of Home Depot, and the LLM is the solutions expert.

Re: Why most product planning is bad and what to do about it

#36

Post by nradov »

procaryote wrote: post #5

Am 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…

There is no one optimal planning horizon. If you have a small team and rapid requirements flux then you might not be able to plan more than a day ahead. But if you're trying to coordinate a huge program with a geographically distributed team, multiple suppliers, hardware components, regulatory compliance issues, etc. then you might have to plan even more than a quarter ahead to avoid complete paralysis.

Re: Why most product planning is bad and what to do about it

#37

Post by fredfli »

brightball wrote: post #35

This sounds like PI Planning. Fwiw, I have become a huge fan of the approach from ShapeUp with 6 week cycles followed by a 2 week cool down.

6 weeks is a long time. Is the benefit that you spend more time writing code rather than being in meetings?

Re: Why most product planning is bad and what to do about it

#38

Post by jason_oster »

apsurd wrote: post #18
0xbadcafebee wrote: post #13

> 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…

Isn't software never being finished a unique trait of software and therefore intentionally used as a value? I get that never-done software tends to justify shitty products. But how would you suggest taking advantage of software's features vs do you really recommend building it like a bridge?

> You just cobble something together to sell. It need not be any good. As long as you can fool people into buying it, you can always try to make better versions later.

> 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

Re: Why most product planning is bad and what to do about it

#39

Post by 0xbadcafebee »

apsurd wrote: post #18
0xbadcafebee wrote: post #13

> 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…

Isn't software never being finished a unique trait of software and therefore intentionally used as a value? I get that never-done software tends to justify shitty products. But how would you suggest taking advantage of software's features vs do you really recommend building it like a bridge?

You could keep whittling on a chair leg forever, but I don't think that's a value.

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.

Re: Why most product planning is bad and what to do about it

#40

Post by QuercusMax »

lemonlearnings wrote: post #24
procaryote wrote: post #5

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

3 months feels like a good cadence to get everybody in a room together, especially if you have geo-distributed teams or product / sales folks who are on the road a lot.
Post reply on HN