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.
> you don't need that plan because it's just an arbitrary block of pretty fungible work
This is an over-generalization. If you are a team of 5 selling a B2C product, sure.
But for B2B you tend to need to commit to a roadmap eventually, hence planning.
And for bigger orgs with multiple teams, if you want to commit to x-team initiatives then longer timeframes can help with coordination. (Ie- we want to deliver X in Q4, therefore A and B should be done in Oct, so that C can begin in Nov)
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.
"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!
> "Focus on problems, not solutions" is pretty standard practice.
You'd be surprised. Especially as you go further from tech, or tech minded companies. Dont get me started on more regulated stuff in manufacturing. Ive met so many value stream managers, site managers and even directors who simply cannot comprehend how fancy system X wont solve everything
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
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…
> 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”.
The 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.
>> 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.
17 comments
[ 3.0 ms ] story [ 40.0 ms ] threadThe font is extremely thin which makes it unnecessarily hard to read.
A lot of jargon and abbreviations also hinder understanding.
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.
This is an over-generalization. If you are a team of 5 selling a B2C product, sure.
But for B2B you tend to need to commit to a roadmap eventually, hence planning.
And for bigger orgs with multiple teams, if you want to commit to x-team initiatives then longer timeframes can help with coordination. (Ie- we want to deliver X in Q4, therefore A and B should be done in Oct, so that C can begin in Nov)
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.
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!
You'd be surprised. Especially as you go further from tech, or tech minded companies. Dont get me started on more regulated stuff in manufacturing. Ive met so many value stream managers, site managers and even directors who simply cannot comprehend how fancy system X wont solve everything
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
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.
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.
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.
Fwiw, I have become a huge fan of the approach from ShapeUp with 6 week cycles followed by a 2 week cool down.
I always found the hardest part of planning was “we need a few more days we are almost done” that stretches to infinity.