[HN Gopher] Why most product planning is bad and what to do abou...
___________________________________________________________________
Why most product planning is bad and what to do about it
Author : ndneighbor
Score : 68 points
Date : 2025-10-02 19:34 UTC (3 hours ago)
(HTM) web link (blog.railway.com)
(TXT) w3m dump (blog.railway.com)
| colonwqbang wrote:
| Meandering post which struggles to get to the point.
|
| The font is extremely thin which makes it unnecessarily hard to
| read.
|
| A lot of jargon and abbreviations also hinder understanding.
| TuringTest wrote:
| You can skip to the "The Four-Day Process" at the end to get
| the gist.
|
| But for people living in an organisation suffering from those
| problems, reading how other solutions were tried and how they
| failed is valuable, and it puts things in context of why the
| recommended approach may work best.
| stackskipton wrote:
| As someone who has been at multiple organizations suffering
| from planning hell, most of the time the solution is pretty
| clear but outside factors prevent 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_
| apsurd wrote:
| You got downvoted but then I read some and you're not wrong.
|
| I think we should call out bad writing assuming English is
| their first language. Bad, lazy writing, doesn't respect the
| audience.
|
| > Instead of crowd sourcing the OKRs from the company and
| bubbling them up per function.
|
| First sentence under the heading "Good Ole Projects". This is
| not a sentence.
|
| edit: The charitable pov is that writing is very hard work and
| writing and publishing anything is a net good. I wish for more
| people to respect how hard writing is and also to take the time
| to write well! So that's why that sentence bothered me.
| ndneighbor wrote:
| Author here, not my intent! My deepest apologies. English is
| my first language but people do joke that they say I write
| English like I learned it as a second language.
|
| I have fixed the sentence fragment and connected the two
| thoughts together. Thank you for keeping me honest.
| apsurd wrote:
| I just edited my comment! I do not wish to convey negative
| energy toward something you made. I felt bad about it.
|
| Also, I do care about writing, so thank you!
| datadrivenangel wrote:
| Weighted Shortest Job First with clear articulations of value is
| the way. This problem driven development approach seems like a
| decent take on that.
| procaryote wrote:
| 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 month
| plan wont last a week before becoming obsolete.
|
| If you need to build a bigger thing that is only valuable once
| it's all done, you A: need a project and B: probably don't
| because it will fail.
| ndneighbor wrote:
| 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 eng. resources we could have more
| people than problems and we could take stuff on board as it
| arrives, but for us deciding on what to work on is a hard
| decision.
|
| I also agree that market fit is a key factor. I think Railway
| was lucky that we didn't have to pivot the product 3 to 5 times
| to get some latch.
|
| What would be the post-quarterty planning process that you
| would like to see?
| __alexs wrote:
| There is no world where you have more people than problems
| because the more people you hire the more problems they
| discover.
| collingreen wrote:
| > 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.
| zer00eyz wrote:
| Most planing is bad for two reasons that we never talk about.
|
| 1. The wrong metrics: Ultimately the only metric that matters is
| money. Is this saving us money, are we wasting money. Every
| feature has a cost, and we are decent about tracking its
| construction costs but not its operational costs. This matters
| when you're paying for every iota of infra on AWS.
|
| 2. No one ever gets promoted for ripping out a feature that costs
| too much to run or doesn't retain customers, or is under used.
| Heath of the product as a whole isnt always about growing the
| business, sometimes it's about running it.
| apsurd wrote:
| "Focus on problems, not solutions" is pretty standard practice.
| Seems like author cherry picks some abstract concept of "bigco"
| and their process-driven planning. I guess.
|
| Came here to say, I don't deny those anecdotes, but just as many
| companies can and do intuit "what problem are we solving?" and
| then come up with some potential solutions in meetings across
| stakeholders. That's called planning. Time-box it and move on to
| some face-reality testing.
|
| Planning anything, in any way, is imperfect. Partly fed by over-
| pontificating about the perfect way to plan!
| lovich wrote:
| I always found product planning went poorly because the bosses of
| the people making the plans would make heads roll if you couldn't
| draw them 7 parallel red lines, 3 of them being perpendicular,
| and in green ink
|
| They'd get a plan that made them happy in the moment, we'd
| inevitably go off the rails in a few weeks but in a politically
| satisfactory way. Mission accomplished would be declared and then
| we'd start all over again next quarter/year.
|
| That is unless you are working under the SAFe framework in which
| case you cut out all that time wasted trying to execute on the
| impossible plan and just doing constant rolling, planning of
| planning
| wrs wrote:
| 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...
| ndneighbor wrote:
| 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 that's
| okay, we then look back at the retro to see what we missed.
|
| If interested, I think we can blog about what happens when a
| problem gets converted to an RFC and then we have more
| engineering discussions with the stakeholders but the piece was
| pushing a 10 min read time as it was...
| 0xbadcafebee wrote:
| > 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 hell scape but (no, no, they all are)
| > and then at times get blindsided every now and then from a new
| business priority or an incident (your executive team is
| disorganized and your operations are unstable; again, normal)
| > we felt that reigniting the agile vs. waterfall armistice
| needed to be torn up
|
| Wait... what? This article _isn 't_ trading on clickbait tropes
| about a black-and-white world for HN points? Ok, I'm listening.
| > We implemented them faithfully, we all read the John Doer book
|
| So you read the 2018 book that was written after a Silicon Valley
| process used by mega-unicorns... but not the 1983 book that
| process was based on? Foreshadowing? I'm going to call it and say
| "they should've read Deming".
|
| As a (lengthy) aside: planning is bad most places because most
| people don't have multiple perspectives. Anyone _can_ have
| multiple perspectives, but it requires both an interest in other
| perspectives, and a means of communicating (and receiving) those
| perspectives. Those are rare commodities.
|
| Sales and executives set deadlines for objectives without talking
| to the people who do the work. They don't have an accurate
| perspective of the engineering (or other) departments. If they
| knew there is no time, and they're crushing the morale of other
| teams (and why that's _very important to avoid_ ), they wouldn't
| commit to things when they don't know if it's feasible.
| Similarly, when engineering gets word they have to throw out
| their current work and rush to finish something else, and they
| had the executive/sales perspective, this demoralizing slog might
| not feel as bad.
|
| Even within engineering, at every job I've had, splitting up
| teams creates dysfunction. Engineers stop understanding the
| entire system's architecture. They stop designing with the other
| pieces in mind. Their perspective becomes a laser beam shot at
| their own navels. This contributes to difficulty planning between
| teams, and invents new problems that have to be planned around.
| If they fully understood each other's perspectives, they wouldn't
| have those issues.
|
| Today nearly all online products are developed with a 2010s-era
| "this is the _only way_ you can make software " mentality. Your
| product is never finished, is constantly changing, re-
| architected, etc. It's cargo cult. You don't have to develop this
| way. You can make online products like physical products. But
| because people today are incapable of thinking outside this
| framework, planning is stuck in this bizarre world of only
| considering a few quarters at a time. This wastes time and money
| and creates more problems. Software architects, product owners,
| and executives, force themselves into working in crappy ways, and
| then struggle to find their footing.
|
| This article is an example of people struggling to find footing.
| Rather than deal with the fact that the way they're working is
| causing them problems, they're instead focusing on how they can
| _plan for_ the work that 's causing them problems. It's like
| having a bum ankle while playing soccer, and rather than stop
| running on the ankle, you're trying to figure out how you can
| continue running on the ankle. Stop doing the thing that's
| causing you problems.
| YZF wrote:
| This. I would also add that people are not
| motivated/incentivized to have those different perspectives.
|
| All of this is very much related to:
| https://en.wikipedia.org/wiki/Conway%27s_law
|
| Your software product is never finished is partly a reflection
| of how you structured your organization. That is often the root
| cause of your problem.
| apsurd wrote:
| 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?
| florakel wrote:
| 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".
___________________________________________________________________
(page generated 2025-10-02 23:00 UTC)