[procaryote]

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]

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]

There is no world where you have more people than problems because the more people you hire the more problems they discover.

[stavros]

Or create.

[ndneighbor]

A man can dream ;-;

[poopiokaka]

It sounds like you actually thought that was an outcome that is possible. Are you the CEO / a decision maker?

[collingreen]

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

[procaryote]

Deciding what to work on is critical as you say, every startup I see have at least 10x the things they want to do compared to the number of people.

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.

[affidavid]

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.

[lemonlearnings]

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.

[procaryote]

If your 3 month plan relies on other teams delivering on commitments, you've coupled your teams success to that other team.

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.

[lemonlearnings]

Yes indeed. I always look for ways to decouple things for this reason even if that decoupling creates a bit more work.

[QuercusMax]

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.

[nradov]

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.

[theptip]

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

[procaryote]

Does the roadmap actually help in the B2B case though? In many companies it's just a way to disappoint the customer a bit now (because the thing they want isn't first on the roadmap) and a bit more later (because the roadmap failed).

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.

[goalieca]

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.