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”.
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.
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?
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 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...
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.
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
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.
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.
"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!
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
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.
> 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.
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”.
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.
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?
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 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...
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.
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.
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
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.
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.
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!
Weighted Shortest Job First with clear articulations of value is the way. This problem driven development approach seems like a decent take on that.
"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!
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
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.
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.
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.
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?