From Chaos to Clarity: Streamlining Your Product Development Process

How to Spend Product and Engineering Resources Wisely

"Time is a created thing. To say 'I don't have time' is like saying, 'I don't want to.'" – Lao Tzu

I see a common pattern when talking to founders and product people at companies of various sizes on how they are constantly so busy with work yet they don’t have anything meaningful to show for it.

This makes everyone else in the company wonder why the product and engineering teams are so busy. What do they keep working on all the time?

It often feels like teams are running a marathon on a treadmill — lots of sweat, zero miles.

One of the big issues is that most people consider progress as new features or new products.

People forget that as the companies get bigger, more and more resources are needed just to keep the lights on.

And then there's the eternal tussle between product and sales — sales want everything yesterday, while product teams are juggling today and tomorrow.

It’s not uncommon for product managers and engineers to spend several months being busy and have nothing to show for it or make a meaningful justification on where the time was spent.

The knee-jerk reaction? Hire more product managers and engineers. But this is akin to adding more chefs to an already chaotic kitchen; what's needed instead is a clear menu and a well-orchestrated kitchen brigade.

One way to get alignment on the product roadmap with everyone in the company is by categorizing the roadmap with several themes. Here’s what I used when building products and it worked for us:

• Metric Movers: Features you have high conviction will make a direct impact on your key metrics - revenue, retention, reducing churn, growth, engagement, conversion rate, etc.
• Technical Debt/Infrastructure/Dependencies: Regularly reduce technical debt to prevent it from stifling new development. Address infrastructure changes for better performance, security, prevention, and improving development velocity. For multi-product companies, consistently manage inter-product dependencies.
• Internal Tools: As the company scales up, you will have several people overseeing operations and preventing problems. They need dashboards, reports, automation, notifications, etc., to do their jobs. However, with AI and many dashboard and automation tools that allow non-technical people to do what they need, I believe this wouldn’t have to increase much if the right structure is set up early on.
• Customer Requests: Features and changes customers have asked for. However, not everything a customer asks for should be built. This is a topic on its own and how difficult it becomes to manage this if you have a large revenue concentration with a few enterprise customers.
• Experimental Bets: Things that you don’t have enough validation on that it will move a key metric, but it’s an experiment or a hunch you want to test. Most companies do this pre-PMF but stop doing this once they found some validation, which I believe is a big mistake. There is a lot of value in building a culture of experimentation and not to mention most companies end up pivoting or building highly lucrative verticals from a small weekend experiment.

Keep in mind they are not all mutually exclusive. A customer request can also be a metric mover.

Allocate engineering and product time across these themes accordingly.

Of course, the pressing question is: How do you decide the time allocation? There's no straightforward rule here; it varies based on your company's stage, product type, and available resources.

If you're not post-PMF, stop reading this right now. Go talk to your customers. Do whatever it takes to reach PMF!

For companies post-PMF, here's my advice:

Don't obsess over exact percentages. It's crucial that product and team leads have a clear mental picture of where most of the time is being spent. This ensures everyone is aligned on what defines success.

The allocation varies depending on your stage, product type like Enterprise SaaS, Self-Service SaaS, Marketplace, Dev tools, etc.

This assumes you're mainly a single-product company. If you have multiple products and teams, you'll need to repeat this exercise for each product in your portfolio. Because each product will have a different growth curve and maturity stage and hence each of them will need its own resource allocation plan to get the best returns.

For Series A companies, which likely recently achieved PMF, the focus should be on growth. Allocate most of your time to metric movers, while managing technical debt that could slow you down later.

At Series B, the focus often shifts to geographic expansion, building multiple product teams, and transitioning from a fledgling startup to a more stable, predictable company. This is when people and team issues often arise, especially with interdependent teams. Addressing these issues typically offers the highest leverage.

By Series C, your core product is likely maturing. Now, the goal is to build new products and business verticals for Lifetime Value (LTV) expansion. Companies at this stage should focus on experimentation to find PMF in their new products and verticals.

In essence, the art of product management lies in balancing the present needs with future aspirations, ensuring that the team's efforts translate into tangible outcomes.

It's a continuous dance of prioritizing, aligning, and re-aligning resources to the rhythm of your company's growth and market dynamics.

What does your product planning and resource allocation look like?