Except over time, those “rational” decisions silently reshape your entire product ecosystem. Critical flows end up scattered across different tools. Data and logic moves outside your core product. Roadmap priorities start to follow vendor’s strategy rather than your own.

The real problem isn’t whether you buy yet another tool.
The problem is when you accidentally move parts of your core product outside your control.

That’s why I believe that

Build vs buy is not a procurement question. It’s a product strategy decision.

From “Tools” to “Ecosystem”

Let’s shift the question.

Instead of asking: “Should we build or buy this feature?”
Ask: “What does our product ecosystem look like, and where does this new capability fit?”

By product ecosystem I mean the full set of capabilities your users rely on, the end-to-end journey they experience, and the underlying systems that hold your data and decision logic.

Your goal is to create one coherent experience for your users, even if behind the scenes you assemble it from built components, bought tools, and integrations.

So before you start discussing solutions, map the user journey for your primary personas and mark the moments where users would say: “This is the product.” Treat those moments as sacred. They are prime candidates for building or deeply embedding into your core product.

Everything else is negotiable.

Principle 1 – Start From the User Journey, Not the Feature List

Most build vs buy conversations start from a feature: “We need advanced analytics / a shift-planning tool.” The problem is that features live in isolation; users don’t.

Start with the user journey instead. Where do users log in first? Which screens do they spend the most time on? Where do they make decisions that actually matter – approving, rejecting, prioritising, paying? Only then ask where the new capability fits in this flow.

A simple rule of thumb:

If users experience the feature as “the product”, lean towards building or deeply embedding it.

That doesn’t mean writing everything from scratch. It means your product owns the experience, while any external tools stay largely invisible. The user should feel like they’re using one product, not being moved out into “another system”.

Principle 2 – Differentiate vs Hygiene

Not every capability deserves the same level of attention.

Some are differentiating: they directly contribute to your unique value proposition, make your product hard to replace, and give you leverage in sales conversations. For example: a proprietary optimisation engine or domain-specific workflows.

Others are hygiene or commodity: customers expect them, but they don’t choose you because of them. Email sending, generic dashboards, ticketing – there are plenty of good vendors in these spaces, and you won’t win by building your own and then maintaining it forever.

The rule of thumb here is:

Protect your differentiation; don’t reinvent hygiene.

In reality, you’ll encounter a lot of grey areas. Something that starts as hygiene (“basic reporting”), can, over time, become a key part of your differentiation (“we provide unique and actionable insights”). That’s why you need a repeatable way to revisit earlier decisions. We’ll come back to this when we talk about governance.

Principle 3 – Decide Where the “Brain” Lives

This is the principle most teams skip.

You can plug in many tools and integrations, but you should be very intentional about two things:

• where your core domain data lives (customers, contracts, orders, etc), and

• where critical decisions are made (pricing, routing, approvals, etc).

If you move too much of the brain into SaaS tools, you end up with vendor lock-in that’s very hard to unwind. You will have very little flexibility when you want to change how things work.

The guideline I use is:

Own the brain, rent the limbs.

Rent generic functionality. But own the data models and logic that make your product valuable in your specific domain.

Owning the brain doesn’t always mean building everything yourself. It does mean that your product holds the source of truth for core entities, and that core decision logic lives in your services, not inside complex vendor configurations.

Principle 4 – Respect Your Operational Reality

And then there’s the real world: limited team capacity, budget constraints, time-to-market pressure.

You can’t ignore any of that. But you also shouldn’t let it dominate the conversation from the start.

What usually works well is to first decide where a capability ideally belongs in your ecosystem – core product or integrated tooling – and only then overlay reality:

• Can we build this well enough in the timeframe we have?

• Do we have the skills to maintain it?

• What will we deprioritise on the roadmap if we build it?

• If we buy, what does the vendor roadmap look like, and how much lock-in are we accepting?

Rule of thumb:

Your product strategy decides what you would do. Time, capacity, and budget adjust how and when you do it.

Sometimes you’ll consciously decide: “Ideally we would build this, but we can’t afford to right now. We’ll buy a tool and review in 12–18 months.” That’s fine – as long as it’s intentional and documented, not accidental.

A Simple Build vs Buy Decision Matrix

Here’s a simple matrix you can use as a general guideline.

Low differentiation / Low criticality
Think about internal expense tracking for your own team. It needs to work, but it’s not why your product exists. The answer is simple: buy something off the shelf, integrate it lightly, and don’t spend more energy here.

Low differentiation / High criticality
Compliance reporting is a good example: customers don’t choose you for it, but mistakes can have serious consequences. In this quadrant you usually still buy, but you design solid data integrations and make sure you can switch tools later without risking your data or your obligations.

High differentiation / Low criticality
Here you’ll find niche features that delight a specific segment of your users. They may not be business-critical, but they can strengthen your positioning. This can be a good space to build, especially if you can iterate quickly. It’s a natural place for experiments and small MVPs.

High differentiation / High criticality
This is where your routing engine, pricing logic, or other core logic live. This is central to your value proposition and risky to outsource. You typically build and treat the capability as a strategic product investment. You want control, flexibility, and deep integration with the rest of your ecosystem.

The matrix doesn’t replace judgement, but it forces you to articulate why you’re deciding one way or another.

Example

Let’s show this on a concrete example.

Imagine FleetFox, a company that optimises last-mile delivery for retailers. Their core promise is: “We help large retailers deliver faster and cheaper, with fewer failed deliveries.”

Their core product is an optimisation engine and a dispatcher console for operations teams. The main users are retailers’ ops managers, FleetFox’s own operations team, and drivers on the road.

As FleetFox grows, they face several build vs buy decisions.

Decision 1 – Driver performance & safety score

Management wants better visibility into driver performance. They don’t just care about on-time delivery; they also want to combine customer feedback and safety signals like harsh braking or speeding.

This is at the heart of their value proposition: reliable delivery, fewer incidents, a better experience for the retailer’s customers. If they get this right, it can become a clear differentiator: “We don’t just ship parcels; we help you improve your fleet.”

The “brain” here lives inside FleetFox. Delivery outcomes, telematics data, and complaints are all core domain events. They form a unique picture of performance that generic tools don’t understand out of the box.

So they decide to build this capability as part of the core product, and, where useful, buy specific components under the hood. “Driver performance and safety score” becomes a first-class concept in the FleetFox product, not just a metric that is part of someone else’s dashboard.

Decision 2 – Incident reporting & ticketing

Next, retailers ask for a better way to report incidents like damaged packages or missing shipments. They want to log a case and see it’s progress through to resolution.

This matters, but it’s not the core differentiator of the product. Every logistics provider needs some form of incident management; very few are chosen specifically because of it. This fits in the category High criticality/Low Differentiation.

Incidents do need to connect back to FleetFox’s core entities – shipments, routes, drivers – but the basic ticketing flow is commodity.

The team is already stretched on the optimisation roadmap, and there are plenty of mature ticketing products with good APIs. FleetFox therefore decides to buy a ticketing tool and build only a thin integration layer:

• Retailers create and view incidents inside the FleetFox UI.

• Behind the scenes, incidents are synced to the ticketing system.

• Core data about shipments and routes continues to live in FleetFox.

To the retailer, it feels like one product. To FleetFox, it’s implemented via a bought tool.

Decision 3 – Internal shift-planning tool

Finally, FleetFox’s own operations team needs a way to plan driver shifts better. This is an important internal problem, but retailers never see it.

From a product strategy perspective, this clearly sits on the “low differentiation” side. Good shift planning helps FleetFox run efficiently, but nobody buys FleetFox because of the internal tool. Some constraints and data points need to come from the core system, but overall this is an internal process problem, not a core product capability.

On top of that, there is zero capacity to build and maintain a custom internal planner, and the market is full of tools that already solve this well.

So FleetFox chooses to buy an off-the-shelf planning tool and integrate it lightly: export/import, maybe a few data syncs and no complex deep integration. They’ll only revisit this decision if their scale or complexity increases to the point where it starts touching the core value proposition.

Making Decisions Stick

You do not need a large governance structure for every build vs buy question, but it helps to have some structure to make decisions consistent and traceable.

A useful first step is to define and document a small set of principles. For example: distinguish between differentiation and hygiene; own the brain, rent the limbs, etc. When these principles are written down and shared, discussions and decisions flow easier.

For more significant decisions, it is worth using a single-page decision note. This should briefly describe the problem and user journey, indicate where the capability sits in your ecosystem, position it on the differentiation/criticality matrix, summarise the options considered, outline key risks such as lock-in or maintenance, and state the final decision with a next review date. The goal is clarity. Someone joining later should be able to understand why the decision was made.

It is also important to know who participates in the decision. Typically, Product represents the customer problem and value, Technology is responsible for architecture and feasibility, Finance covers cost and contractual aspects, and the relevant business stakeholder brings the business perspective. In most cases, this is sufficient.

Common Anti-Patterns

There are a few common anti-patterns that I find worth mentioning.

The tool sprawl. Different teams adopt their own tools independently, and you end up with multiple logins, overlapping functionality, and a fragmented experience for both customers and internal users.

“We can build anything” syndrome. Teams are confident in their ability to build and gradually recreate commodity capabilities that could have been purchased. Over time, this translates into a heavy maintenance burden and less capacity for valuable differentiating work.

Vendor as product. Core flows migrate into a SaaS platform, and your own product becomes a thin layer around it. You lose flexibility and power because key decisions and data structures effectively live in someone else’s system.

Silent lock-in. Dependence on a vendor becomes visible only when you attempt to switch and discover that migration is complex, expensive, or simply not feasible with the current setup.

Be aware of these anti-patterns. This will make it easier to recognise when a seemingly harmless decision is moving you towards an undesired direction.

Before Your Next Decision

For your next build vs buy discussion, start with a short set of questions:

• User journey. Will users experience this as “the product” or as a background function?

• Differentiation. Does this capability meaningfully support how we win or stand out in the market?

• Brain vs limbs. Does it touch core domain data or decision logic we must own and control?

• Criticality. What is the impact if this fails or is unavailable for a day? For a week?

• Time and capacity. Can we build and maintain this without derailing more important roadmap work?

• Vendor risk. If we buy, how easy is it to export data and switch later? Does the vendor’s roadmap align with where we want to go?

• Review horizon. Are we making a permanent decision, or a 12–18 month bridge solution that we plan to revisit?

Capture the answers on a single page and use them when later you revisit the decision.

Build vs buy is not only about saving money or shipping faster. It is how you design your product ecosystem: deciding what you own, what you rent, and how it all comes together into a coherent experience for your users.

Enjoyed this read? Subscribe to Lean Product Growth for regular updates on building and scaling a successful product organization.

Subscribe now

Most product leaders know the pressure: define a roadmap, align teams, deliver impact—while the ground keeps moving under your feet. Budgets shift, technology blockers pop up, and leadership reorients priorities.

So how do you create a roadmap that is grounded with reality?

Let’s reframe how we think about roadmapping.

1. Stop Treating Your Roadmap Like a Project Plan

The biggest mistake? Treating the roadmap like a schedule.

A roadmap is not a predefined plan with locked timelines. Planning makes sense when your context is predictable and execution is repeatable.

But in fast-changing environments, committing to fixed timelines can backfire. You risk two common outcomes:

1. The roadmap becomes disconnected from reality—in over 60% of teams, plans become partially or fully obsolete within 3–6 months due to shifting priorities or new insights.

2. Teams focus on hitting the plan just to meet the target—even if it means sacrificing customer value or shipping the wrong thing.

That doesn’t mean timeline-driven roadmaps are always wrong. They’re essential when deadlines are real—like regulatory launches, competitive market windows, or major company events such as divestments or rebrandings that require strict timing.

The key is to know when you’re optimizing for a fixed timeline—where hitting a specific date matters most—and when you need to preserve adaptability to adjust based on new insights, feedback, or shifting priorities.

2. No Strategy, No Roadmap

You don’t start building a roadmap before understanding your higher strategic goals.

These goals should be clearly defined, aligned with leadership and stakeholders, and understood across the organization. They are the foundation that informs prioritization, trade-offs, and where you place your bets.

When this step is skipped, teams often find themselves misaligned later—arguing over roadmap details while working toward fundamentally different definitions of success.

Get aligned early to avoid chaos later.

3. Roadmaps Are Bets—Not Guarantees

Think of your roadmap as a living portfolio of strategic bets—initiatives you choose to invest in because you believe they’ll help achieve your product and business goals.

What is a bet?

A bet is a strategic initiative made under uncertainty. You’re not guaranteeing success—you’re placing a calculated risk based on what you currently understand about the problem and the opportunity.

A good bet:

• Acknowledges uncertainty: You might be wrong—and that’s part of the process.

• Encourages learning: Whether the outcome is success or failure, you gain valuable insights.

• Reflects trade-offs: Every bet means deprioritizing something else.

Example:

“We bet that improving onboarding will increase activation by at least 20%.”

Each bet is broken down into smaller steps—experiments, milestones, or features—that help you validate assumptions and adjust course as you learn.

With each step, your confidence should either grow—or you should realize it’s time to pivot.

This is the heart of adaptability.

Roadmaps must evolve because:

• Your teams are learning: What works, what doesn't, and what users actually value.

• The world changes: User expectations shift, new technologies emerge (think about generative AI breakthroughs that made entire roadmaps irrelevant almost overnight), or competitor moves reshape the landscape.

If your roadmap stays the same for 3–6 months, ask yourself: are we learning and adapting—or just sticking to the plan because it’s the plan? it likely means one of two things:

• You made all the right assumptions upfront (possible, but unlikely), or

• You’re ignoring new information and missing opportunities to adapt (much more likely).

4. Refresh Quarterly—But Stay Ready to Pivot

How often should you update your roadmap?

There’s no universal answer—but for most teams, quarterly is the sweet spot.

A quarterly rhythm strikes the right balance:

• Not too slow—unlike half-yearly cycles, which can leave you out of sync with new insights or shifting priorities.

• Not too fast—unlike full monthly planning cycles, which often consume too much time and disrupt execution with frequent interruptions.

Quarterly planning gives teams enough time to make real progress, while creating space to reflect, adapt, and stay aligned with the bigger picture.

Of course, not everything fits a fixed rhythm. Sometimes you’ll need to update mid-cycle—when something big changes. For example:

• A new product leader joins

• A major opportunity or threat emerges

In those moments, refresh early. Don’t wait for the calendar.

And whatever your cadence, build in slack: leave 15–30% of your roadmap open for emergent priorities. That’s where your most valuable insights, innovations, and pivots often come from.

5. Make Your Roadmap Heard

A roadmap only delivers value when it's clearly communicated to the right people, at the right time.

There are two key audiences to communicate with.

Your team

Involve them early. Share context before planning starts, involve them in trade-offs, and keep them updated.

When teams feel connected to the vision, they work like missionaries, not mercenaries.

Internal stakeholders

Inform groups like sales, marketing, and customer support once the roadmap takes shape. Share what’s coming, invite feedback, and adjust if needed. Good ideas can come from anywhere.

Finally, publish it. Share it in leadership forums, team rituals or integrate it into the tools your teams use daily (like Confluence or Notion). If people can’t find or explain your roadmap, it’s not doing its job.

A roadmap reduces chaos when it’s visible, understood, and shared widely.

6. Roadmap Frameworks That Help

You don’t need complex frameworks or expensive tooling to manage an adaptive roadmap. The goal is to make strategy visible, priorities clear, and decisions traceable—without burdening teams.

Here are a few frameworks that are a great start.

• Strategic themes over feature lists: Group roadmap items by outcome-driven themes (e.g., activation, retention, revenue expansion) instead of individual features. This helps teams stay aligned on purpose, not just output.

• OKRs that cascade from roadmap focus areas: Tie quarterly objectives directly to roadmap themes to ensure alignment from leadership vision to team execution.

• Opportunity Solution Trees: A visual framework popularized by Teresa Torres to explore multiple ways to solve a problem and avoid locking into the first idea.

• Balance your bets across time horizons: A strong roadmap includes a healthy mix of initiatives—some that improve and scale your core product, some that explore adjacent opportunities, and a few that aim to shape the future. See: McKinsey’s Three Horizons Model.

Five Golden Principles to Take With You

Let’s recap the five golden principles for roadmapping in a fast-changing environment:

1. Avoid overplanning: Don’t overfit a 12-month roadmap when everything changes in 3 months. Instead, build for flexibility and structured re-evaluation.

2. Focus on outcomes, not features: Feature lists hide the "why" and create rigid expectations. Use themes and goals to guide iteration.

3. Create strategic slack: Leave intentional space (15–30%) in your roadmap to handle emergent work, insights, or unexpected shifts.

4. Make the roadmap shared and speakable: Everyone should be able to tell the same story about where you're headed and why.

5. Let learning drive decisions: If nothing changes, ask whether you're truly learning—or just ignoring the signals.

You can build a 12-month roadmap—just don’t pretend you can predict the future.

"Want my 1-pager roadmap template for fast-changing teams? DM me or reply and I’ll send over an excel file.

Enjoyed this Article?

Subscribe to Lean Product Growth for regular updates on building and scaling a successful product organization. Don’t miss out on insights, strategies, and actionable tips—delivered straight to your inbox.

Subscribe now

The sprint started yesterday. Just the team didn’t know. Neither did you.

The goal? Ship something in two weeks.

The product direction - unclear. Everyone has a different take.
The architecture? Already decided — not by consensus, but by chasing quick wins.

Tensions are simmering. Debates are heating up, the foundation still feels shaky.

And yet, the clock is ticking.
You’ve been asked to lead. To move forward.

Everyone’s in a hurry. Including you.

Vision vs. Velocity: It’s Not One or the Other

As chaotic as it feels, this isn't unusual — especially in a fast growing company.

Teams form fast. Deadlines are aggressive. Product direction is still evolving when execution begins.
In these moments, it’s tempting to believe that velocity is winning over vision.

But that’s a false choice.

Vision and velocity aren’t in conflict. They need each other.

• Velocity without vision? You move fast... but in the wrong direction.

• Vision without velocity? You’ve got a great deck. But no product.

The real challenge — and skill — is leading with velocity while shaping the vision.

How to Lead with Vision and Velocity

Here are six principles to help you lead with clarity, keep momentum, and build trust — even when the path ahead isn’t fully clear.

1. Do You Feel In Control?

If not, take a moment to reset — because how you lead depends on how you feel inside.

You won’t fix everything at once. That’s not the job.
Your role is to lead forward from where you are — with calm, clarity, and intent.

Start by accepting what’s outside your control: timing, past decisions, shifting priorities, or any boundaries.
Then focus on what is within your control: how you show up, the questions you ask, the tone you set, the direction you frame.

Make yourself this promise:

I’ll do my best with what I have. And

I won’t take things personally.

These are two principles that Don Miguel Ruiz states in his book The Four Agreements.

This mindset creates space. It frees you to act without absorbing everything. And that makes all the difference when you're leading in motion.

2. Be Transparent — Or Risk Losing the Team’s Trust

In times of ambiguity, people fill in the blanks. And those blanks are rarely filled with optimism.

If you don’t share what’s happening — what’s clear and what’s still in motion — your team will make assumptions. That’s how doubt steps in. That’s how trust erodes and frustration builds.

You don’t need to have all the answers. But you do need to be honest:

“Here’s what we know. Here’s what’s still evolving. Here’s how we’re approaching it.”

Invite concerns. Let people express what’s on their mind. You’ll discover the assumptions they’ve made — and you’ll have a chance to course-correct their thoughts. And maybe, just maybe, bring their optimism back.

Because when trust goes up, friction goes down. And when people feel heard and informed, they move faster.

3. Separate Vision Work from Execution Focus

If you lead, you must keep developing the vision. But you don’t do it live, in the middle of sprint planning.

Your team needs space to focus. They need a clear near-term goal and the freedom to build without constantly shifting context.

So carve out time for yourself to think strategically. You can’t do that in the 15-minute gap between meetings.

• Block deep work time every week for vision refinement.

• Use focused discussions with a small group to evolve direction.

• Shield your team from the “fog” until you’re ready to share something actionable.

4. Use Small Iterations

You don’t need a perfect roadmap. You need a tight feedback loop.

Every sprint is a chance to learn — not just deliver. Small iterations give you the ability to adjust without losing momentum or confidence.

One idea is to frame your work through the Build–Measure–Learn loop — a core principle from Eric Ries’ The Lean Startup:

• Build something small that tests an assumption.

• Measure what actually happened — not what you hoped would happen.

• Learn what that means for your direction.

Can you start each sprint by asking:

“What do we want to learn in this cycle? What are we trying to prove or disprove?”

This approach turns velocity into insight — and insight into better decisions.

You’re shipping but at the same time shaping your direction.

Shipping is only valuable if it helps you choose your next step with more confidence.

5. Zoom In to Unblock, Zoom Out to Align

One of the most critical leadership skills in a scaleup is knowing when to zoom in on the ground — and when to pull back up.

You can’t lead from a distance all the time. Sometimes, you need to get close to the work: dive into a tricky decision, untangle a dependency, or help resolve a missing skill or resource.

But don’t stay there.

Once the path is clear and the team is unblocked, zoom out and ask:

• Does this still connect to our broader direction?

• Are we solving the right problem?

• Did we learn anything that should shape or shift our course?

Your value isn’t in staying close to every detail — it’s in knowing when your involvement accelerates progress and when your distance creates space for ownership.

6. Build Micro-Rituals for Stability

When everything around you is shifting — the team, the goals, even the product — a bit of structure can be grounding.

But too much, too soon? That just creates rigidity you'll need to undo later.

Start small by introducing some lightweight rituals. A few simple examples:

• A short Monday priorities sync

• An end-of-week “what we learned” reflection

• A shared doc for open questions or team-wide decisions

These micro-rituals help your team find rhythm in the chaos. They create a foundation to build on. As the vision matures, your ways of working can evolve naturally with it.

You’re not designing the final process. You’re creating just enough stability to keep moving forward.

Why Holding Both is the Real Work

Leading in a scaleup is not about having a perfect vision or delivering at a high speed. It’s about holding space for both.

You’ll need to show direction before the map is fully drawn.
You’ll need to keep things moving when you’re still figuring out where you’re going.
You’ll need to be transparent, calm, decisive — often at the same time.

It’s not about picking between vision and velocity, but learning to live in the tension.

Some weeks, you’ll lean heavier into strategy. Other weeks, you’ll be down in the details, unblocking and adjusting.

And as Morris Chang said:

Without strategy, execution is aimless. Without execution, strategy is useless.

And the leaders who do this well?
They don’t just ship faster.
They don’t just get alignment.
They build teams that can thrive in uncertainty and grow stronger every day.

Enjoyed this Article?

Subscribe to Lean Product Growth for regular updates on building and scaling a successful product organization. Insights, strategies, and actionable tips—delivered straight to your inbox.

Subscribe now

For early-stage startups, smart spending can mean the difference between survival and failure.

For scaleups, the challenge shifts—they must prove their business model is scalable to attract investors and sustain long-term growth.

Larger organizations, meanwhile, often struggle with internal politics, inefficient processes, all of which drain resources without adding real value.

So, how do you reduce costs without slowing down progress or stifling innovation?

1. Hire Smarter Not Faster

People are your largest expense. If the return on a new hire isn’t justified, it quickly turns into wasted cash.

Hiring too early or without a clear strategy is a classic financial mistake scaleups make. The result - paying salaries for bringing inefficiencies, not growth.

And let’s not forget the cost of a bad hire—rushing to fill an open role can cost 50–200% of the person’s salary when they need to be replaced.

Before expanding your team, ask yourself:

Do we truly need more people, or do we need a smarter way to work?

Let’s say your engineering team is constantly behind on feature releases. The backlog keeps growing, deadlines are slipping, and frustration is rising.

The obvious answer? Hire more engineers.

But before opening job postings, ask: What’s really causing the bottleneck?

If developers are slowed down by manual deployments and outdated infrastructure, hiring just another engineer with the same skill set won’t solve the issue. Instead, investing in DevOps automation will. Only then should you hire someone with the right skills to support that shift.

How to Fix It

Look at the Data Before Hiring. A busy team doesn’t always mean an understaffed team. Analyze workload trends—is the demand temporary, seasonal, or truly sustainable?

Fix Inefficiencies Before Expanding Headcount. If inefficiencies exist, adding more people often magnifies the chaos rather than solving it. First, ask: Can automation, better tooling, or workflow improvements fix this instead?

Ensure a Clear ROI for Every Hire. Every new hire should bring a measurable return—whether in revenue, efficiency, or strategic value. If the value isn’t clear, reconsider the need.

2. Master Focus To Maximize Progress

Growing companies are under constant pressure to scale fast. Ask any employee, and they’ll tell you they’re busy. But being busy doesn’t always mean making meaningful progress.

One of the biggest hidden inefficiencies in scaleups is misaligned priorities—too many initiatives, shifting goals, and a lack of clarity about what truly matters. When teams don’t understand the company’s highest priorities, effort gets wasted on low-impact work.

The cost of this inefficiency isn’t always obvious in financial statements, but the waste is real. If employees can’t see how their work contributes to top company goals, execution becomes scattered, and momentum slows down.

How To Fix It

Define Which Metrics Matter. Identify the most important OKR (Objective & Key Result). Consider defining an OMTM (One Metric That Matters) that aligns with your current growth stage.

Create a Culture of Focus. Regularly reassess priorities and cut initiatives that don’t contribute to core goals. Give teams the autonomy to say No to distractions and stay on track.

Categorize Work Clearly. Not all employees will work on critical business operations—some will be in research, innovation, and future bets. That’s perfectly fine—as long as there is a clear structure for prioritizing goals, urgency, and resource allocation.

3. Don't Kill The Innovation Budget

Many scaleups get so caught up in execution that they deprioritize innovation. The irony? Those who fail to innovate may see short-term cost savings, but eventually, they struggle to compete as the market evolves.

It’s like a team so focused on pushing a heavy stone forward that they never stop to build a wheel. The result? Harder work and decreasing productivity.

Ignoring innovation is a long-term cost that doesn’t show up immediately but can have severe consequences down the road.

Take AI as an example—companies that dismiss it today may find themselves too far behind to catch up when it becomes an industry standard.

How to Fix It

Create a Minimal Innovation Budget. Even when cutting costs, R&D should not be the first target. Instead of eliminating innovation, keep a minimal, focused budget that prioritizes practical, business-aligned innovations with clear impact.

Run Innovation Sprints and End Open-Ended Research. Innovation should not mean slow, unfocused projects. Instead, set up structured, time-boxed innovation sprints with clear objectives and success metrics. This prevents research from dragging on without producing real results.

Ensure Innovation Leads To Execution. Keep innovation close to the core business, not isolated in an R&D bubble. Assign owners who are accountable for turning ideas into real, testable solutions rather than just experiments.

4. Optimize SaaS Spending

Tools and license spending can quietly go out of control.

Without a structured process for managing SaaS purchases—which is often the case in smaller and fast-growing companies—teams sign up for tools quickly but rarely review them.

What starts as a few essential tools can turn into an expensive stack that no one fully manages. Without a clear SaaS strategy, companies end up paying for tools they don’t use, tools that serve the same purpose, or enterprise plans with features they don’t actually need.

How to Fix It

Run Quarterly SaaS Audits. Identify and eliminate unused or redundant tools. Track how many seats are actually being used per subscription to avoid paying for inactive accounts.

Implement Procurement Guidelines. Centralize SaaS purchasing to prevent teams from signing up for overlapping tools. Require approvals for new subscriptions, especially when exceeding a certain budget threshold.

Aim for Usage-Based Licensing. Opt for flexible or pay-as-you-go plans plans instead of fixed per-seat licenses. Regularly downgrade or cancel plans that don’t justify their cost.

A well-managed SaaS stack reduces unnecessary spending but also simplifies workflows.

5. Right-Size Your Infrastructure

Cloud infrastructure is another silent cash drain.

A 2024 Kubernetes report analyzed 4,000 cloud clusters and found that companies were using only 13% of provisioned CPUs and ~20% of memory on average—meaning 80–87% of cloud spend was going toward idle resources.

This means that many companies pay significantly for unused capacity while their actual compute needs remain far lower.

Beyond that, early-stage architectural decisions can lock companies into inefficient spending as they scale. A setup that worked at the startup phase might not fit the next stage of growth, leading to overpriced infrastructure and unnecessary complexity.

How to Fix It

Managing cloud costs doesn’t require a full-time team but does need clear ownership. Typically, a small cross-functional FinOps (Cloud Financial Operations) group (involving engineering, finance, and leadership) is responsible for a structured cloud cost strategy.

A strong FinOps practice helps:

Gain Full Visibility into Cloud Costs. Use cloud cost dashboards like AWS Cost Explorer or GCP Cost Tools to track actual cloud spend.

Optimize Resource Allocation. Regularly review provisioned vs. actual usage and shut down underutilized instances. Move to auto-scaling configurations that dynamically adjust based on real-time demand.

Leverage Cost-Saving Strategies. Use reserved instances or committed-use discounts to lower costs for predictable workloads.

Reevaluate Cloud Architecture as You Scale. If your infrastructure was designed for a smaller scale, assess whether it still meets business needs efficiently.

6. Build Features That Deliver Real Value

Another big hidden costs in product development is maintaining features that provide little or no value. Many teams invest time and resources into building, refining, and supporting features that customers don’t actually use.

At the startup stage, it’s common to experiment and iterate quickly, often making gut-driven decisions about product direction. But as a company scales, continuing to build without validating demand leads to a bloated product, increased maintenance costs, and wasted engineering time.

Many scaleups fail to transition from an intuitive approach to a data-driven one, resulting in features that aren’t widely used, don’t contribute to business goals, or become a maintenance burden.

How To Fix It

• Adopt a Data-Driven Feature Validation Process. Scaleups have the data—use it. Track feature adoption, usage trends, and user feedback before committing to full development. Surveys, A/B testing and user analytics can help determine whether an idea is worth building. Set clear success metrics for every feature—if it doesn’t hit engagement or business goals, don’t scale it.

• Regularly Prune Underused Features. Review old features every quarter and deprecate those that aren’t delivering value. Treat feature maintenance as a cost center—engineering time is expensive; only maintain what matters.

• Encourage a Lean MVP Approach. Ship lightweight versions of new features first—validate them before going all in. Prioritize small releases with measurable impact over large feature rollouts based on assumptions.

Final Thoughts

Optimizing spending doesn’t mean starving innovation, and it doesn’t always mean spending less.

What it really means is investing smarter—ensuring that every resource is used effectively to drive the highest possible impact.

Where are your biggest money leaks?

Start with a small waste audit, identify inefficiencies, and prioritize improvements based on business impact. Your future self—and your CFO—will thank you.

Enjoyed this Article?

Subscribe to Lean Product Growth for regular updates on building and scaling a successful product organization. Don’t miss out on insights, strategies, and actionable tips—delivered straight to your inbox.

Subscribe now

How do savvy investors evaluate which companies are positioned for long-term success?

Last week, I had the privilege to have an insightful conversation on this topic with Ben Yoskovitz, co-founder and managing partner of Highline Beta.

Who is Ben Yoskovitz?

Ben is no stranger to the startup ecosystem—he's been building and investing in companies for over 25 years. Since founding his first company in 1996, he has held roles such as VP of Product at multiple startups, including one acquired by Salesforce. Over the years, Ben has worn many hats: founder, product leader and investor. Today he is a cofounder and a managing partner of Highline Beta, a venture studio and VC fund and an author of FocusedChaos, a bi-weekly newsletter on navigating the chaos of building and investing in startups.

Ben is perhaps best known as the co-author of the book Lean Analytics, written together with Alistair Croll. Even more than a decade later, Lean Analytics remains a must-read in the product management world. Highly recommended if you haven’t had the chance to dive into it yet ⭐.

Q: What Led You To Found Highline Beta?

Ben: The driving force came from my diverse experience over the years. I've been in the startup world for a long time and always enjoyed the early-stage, hands-on work—validating problems, building the first version of a product, and getting it to market. At the same time, I was also passionate about investing and helping founders bring their visions to life.

In 2016, I decided to combine these passions into a new venture—and that’s how Highline Beta was born.

At Highline Beta, we’re not just passive investors. We’re actively involved in incubating ideas, building founding teams, and guiding startups from inception to scale. We help founders avoid common pitfalls by leveraging the lessons we've learned from our own experiences.

Q: What Key Factors Do You Consider When Evaluating Early-Stage Investments?

Ben: Our investment criteria differ from those of traditional venture firms. At this stage, we’re not overly focused on market size projections or detailed financial models.

First, we validate whether there is a meaningful problem that truly needs solving. It’s not enough to have a novel idea—we want evidence that customers are experiencing this problem and are willing to pay for a solution.

Domain expertise is also crucial, especially for first-time founders. A doctor who understands the medical system, for example, has insider knowledge that gives them an advantage to identify the right problem and craft an effective solution.

And, of course, we evaluate the founding team itself—their passion, skills, and ability to execute. Even with a strong idea, success ultimately comes down to whether the founders have what it takes to turn it into a scalable business.

At this stage, investing is largely based on promise, there is little data to look for evidence. At the early stage, a product often does not even exist. Or it might exist but there is limited data to rely on.

Q: How Does Investors’ Approach Evolve as Companies Move to Series A, Series B and Beyond?

Ben: The evaluation process shifts significantly in the transition from Seed to Series A.

By the Series A stage, the approach becomes much more analytical because there is now meaningful data to assess whether the company is healthy and on a positive growth trajectory. This is when business metrics become important.

At Series A and B, market dynamics play a bigger role. At this stage, the product is better defined, and the target market is clearer. It now becomes important to assess market conditions, competitive landscape, and the company’s ability to establish a strong market position.

While the leadership team remains a critical factor, expectations rise. We need to see not just passion and potential, but proven execution—a team capable of scaling operations and delivering on growth objectives.

Q: What Are Some Key Metrics At Those Later Stages?

Ben: At a later growth stage, revenue and growth metrics become critical—things like revenue per customer, average deal size, and sales efficiency. The goal is to assess whether the underlying economics of the business model are sound and can support sustainable growth.

Investors also start paying closer attention to operational metrics, such as revenue per employee. As headcount grows, maintaining productivity and efficiency becomes crucial—inefficient scaling can be a real killer at this stage.

And, of course, even at later stages, customer satisfaction metrics—like churn, retention, and product usage—remain essential. Maintaining a sticky, loyal customer base is key to long-term success.

That said, while metrics are incredibly important, companies need to be thoughtful about how they use them. As businesses scale, it’s easy to get lost in a sea of data. Teams often optimize for their own departmental metrics without tying them back to the company’s overarching goals. Product is shipping features, marketing is running campaigns, and sales is closing deals—but busyness doesn’t always translate into meaningful progress.

In my book Lean Analytics, we introduced the concept of One Metric That Matters (OMTM). The idea is simple: at any given stage, there should be one key metric that the entire company aligns around and focuses on improving. It’s not about tracking a million different numbers—it’s about identifying the single most important indicator of the company’s health and success at that moment. Each team’s efforts should ultimately connect back to this one metric to ensure alignment and real impact.

Q: How Do Investors Look at Leadership as a Company Grows?

Ben: Founders need to understand that leadership evolves dramatically as a company scales.

In the early days, they’re deeply involved—coding, designing, selling, and doing whatever it takes to get the business off the ground. But as the team grows, their role must shift from doing the work to leading people and building the company.

That said, I don’t think founders should completely step away from what made the business successful. If a founder has a deep product or design background, staying engaged can be valuable. In fact, their early involvement is often what made the company great in the first place.

But as the company scales, the founder’s job fundamentally changes. They need to learn to delegate, build systems, and empower teams. This transition isn’t easy, and not every founder successfully makes it.

Many founders who have gone through this say they had to completely reinvent how they lead—what worked before simply stopped working.

At 10 employees, you can just shout across the room when code needs to be shipped. At 50+ or 500+ people, you need structured teams, clear processes, and strong managers to keep things running smoothly. Career paths and leadership structures also become essential—not just for efficiency, but to retain top talent and prevent great people from leaving.

Investors pay close attention to leadership skills. They would evaluate if the leadership team has the ability to evolve, scale, and lead a growing organization successfully.

Q: How Much Do Investors Focus on the Technical Side of the Product?

Ben: At the early stage—where I typically invest—the product and technology itself aren’t the primary focus. We’re investing before much is built, and we know that early-stage companies are often developing things that don’t scale. The expectation is that they will iterate and evolve as they grow.

That said, while investors don’t scrutinize the technology itself in the earliest stages, they do assess the team’s ability to scale it later. They’re asking: Do I believe this CTO can grow the business, hire the right people, and build a scalable product? That’s the real focus.

As companies move toward Series A and B, technology and scalability start to matter more. Some investors are highly technical and can evaluate the codebase themselves, while many will bring in technical advisors for due diligence. They want to understand whether the foundation is solid enough to support growth or if there’s major technical debt that could slow the company down.

While technical due diligence happens at Series A and beyond, the bigger question investors are trying to answer is: Does this leadership team have what it takes to scale the business from a technical perspective?

Q: What Are The Key Reasons Scaling Companies Fail?

Ben: Most often, growth slows down as the company gets bigger, while costs continue to rise—you’re hiring more people, making bigger investments, and expanding operations. If costs grow faster than revenue, things start to fall apart. And that’s tough to recover from because, in most cases, the biggest cost is people.

This productivity dip often happens after an investment round, when companies go through intensive hiring. In the early days, everyone is aligned, moving fast, and focused on the same goals. But as the company scales, alignment weakens—people are working hard, but often not toward the same objectives. At that point, companies often face layoffs, which can be a painful experience.

We’re now seeing a new trend: building big businesses with fewer people with AI and automation tools. If this trend continues, companies might need far fewer employees than they originally expected, which would lead to less operational challenges.

Another reason? The founders step back from day-to-day operations. The people who originally drove the vision are now not part of the execution which could lead to dilution of vision—and when that happens, execution starts to suffer.

Then there’s competition. As you grow, competitors take notice. Suddenly, a few Y-Combinator-backed startups are doing the same thing and moving very fast. These small teams are nipping at your heels, forcing you to keep up while navigating the added complexity of a larger organization.

Timing also plays a huge role in whether a company can successfully scale. A business that raised a seed round in a "hot" industry two years ago might find itself struggling to raise a Series A if investor interest has shifted. Take consumer tech—four years ago, VCs were pouring money into it. Now? Not so much.

Ultimately, scaling challenges come from both internal and external factors. Internally, companies struggle with alignment, leadership transitions, and the growing complexity of scale. Externally, timing and shifting market trends can make or break a company’s funding opportunities and long-term viability.

Q: How Do Investors Assess the Clarity of a Company’s Roadmap?

Ben: I believe a roadmap is really an exercise in demonstrating your ability to plan and think through your decisions. Investors want to see that you have a structured approach to prioritization and execution.

But in reality? Roadmaps rarely play out as planned.

There are simply too many variables, too many external factors. Imagine you had a two-year roadmap—which some large software companies do—and then ChatGPT launches. Overnight, every company I know is saying “Our roadmap is in the garbage now because ChatGPT just came out”. Suddenly, they need to shift and adapt to this disruptive shift.

From an investor’s perspective, a roadmap shows you’re organized and have thought things through. But if you’re locking in plans a year out? That’s risky. The best approach is to focus on the next 1-3 months, keep iterating, and adjust as you go. Beyond that, roadmaps should be directional rather than prescriptive. It’s useful to have a vision, but agility is key.

Take Aways

Ben Yoskovitz’s insights provide a thoughtful look at what it takes to build and scale startups effectively.

The journey from startup to scaleup is full of inflection points—moments when what worked before no longer works. The best companies evolve, continuously refining their strategy, execution, and leadership to stay ahead of competition, market shifts, and internal complexity.

For founders and leaders, the key takeaway: scaling isn’t just about doing more—it’s about doing things differently. The companies that recognize this early, and adapt accordingly, are the ones that can succeed in the long run.

Connect with Ben

A big thanks to Ben for sharing his invaluable insights on startups, investing, and scaling companies. His experience and perspective offer a lot to learn from for founders, product leaders or investors.

If you enjoyed his perspectives as much as I did, here’s where you can follow more of Ben’s work:

🔗 Connect with Ben on LinkedIn – Get sharp takes on venture building, product strategy, and scaling businesses.

📩 Subscribe to his newsletter, Focused Chaos – A must-read for anyone navigating the startup journey.

Enjoyed this Article?

Subscribe to Lean Product Growth for regular updates on building and scaling a successful product organization. Don’t miss out on insights, strategies, and actionable tips—delivered straight to your inbox.

Platform teams empower product teams to deliver value faster by providing shared tools, services, and capabilities.

But their power comes with a significant challenge: prioritization.

With multiple teams relying on platform support to achieve their objectives, platform teams often find themselves pulled in different directions.

How do you balance competing demands without sacrificing long-term goals or frustrating your stakeholders?

In this article we explore:

• How platform teams can prioritize their workflows effectively.

• How they can balance immediate needs with organizational goals.

• How to maintain strong, collaborative relationships with product teams.

If you prefer listening, you can follow the key insights from this article in an audio format— AI generated.

What is a Platform Team?

Before diving into solutions, let’s clarify what a platform team is.

In their book Team Topologies, Matthew Skelton and Manuel Pais identify four fundamental team types: Stream-aligned teams, Platform teams, Enabling teams, and Complicated subsystem teams.

For this discussion, we’ll focus on the first two.

Stream-Aligned Teams (Product Teams)

Stream-aligned teams—often referred to as Feature Teams or Product Teams—are the heart of most organizations. We’ll refer to them as Product Teams.

These teams own a single product or service aligned with a specific business domain and are closely connected to the customer.

For example, in a banking organization, a Mobile Banking App Team is a product team. They develop and maintain the app, gather customer feedback, and prioritize their work independently to deliver the best user experience.

Platform Teams

Platform teams, on the other hand, play a behind-the-scenes but equally critical role.

They build and maintain internal tools, capabilities, or services that multiple product teams rely on.

Their mission? To make product teams more autonomous by reducing cognitive load and technical complexity, or minimising duplication of effort among product teams.

For instance, a Salesforce Platform Team might focus on developing the foundational capabilities of a Salesforce platform. Product teams—like sales or marketing operations—can then leverage this foundation to create customer-focused features tailored to their specific business domains.

The success of platform teams is directly tied to the success of the product teams they support.

The Prioritization Dilemma

Platform teams are not fully autonomous.

Their workflow depends on the constant stream of demands from product teams, and these demands can be overwhelming.

Without a clear prioritization framework, platform teams may appear flexible and responsive to other teams’ demands. But this approach comes with substantial risks.

• Burnout from handling endless ad-hoc requests.

• Sacrificing long-term goals for short-term urgency.

• Straining relationships with product teams frustrated by delays or unmet expectations.

Sound familiar? Let’s break this cycle.

Prioritization Framework for Platform Teams

No prioritization framework fits all, but here’s a proven model to inspire you. You can start with it and evolve it further so it aligns your organization’s unique dynamics.

It starts with one core principle: transparency.

• Transparency between teams - fosters improved expectation management and enables better planning across teams.

• Transparency in identifying bottlenecks - essential to uncover challenges in the process and to make informed, effective decisions.

Step 1. Categorize and Prioritize Work by Streams

A platform team cannot manage their workload effectively if tasks are added to their backlog without knowing the request type or its impact.

Begin by reviewing the backlog and categorising tasks into distinct streams. This will provide a clear picture of where the team’s time and effort are spent.

Once the streams are identified, prioritization can be done within each stream, allowing for a more structured approach.

This could typically look like this.

Stream 1: Ad-Hoc Support & Maintenance Requests

These are small tasks requested by product teams. Fixing bugs, making small adjustments to APIs, or providing troubleshooting support are good examples for this.

Dedicate a portion of the team’s capacity (e.g., 30%) to handle these requests while avoiding disruption to other streams.

Very often, ad-hoc tasks are time-sensitive, requiring immediate attention as they block the product team workflow. If that’s the case, address them immediately. If it is an issue discovered with no urgency to address it, you can save it with lower priority.

Stream 2: New Feature Requests from Product Teams

Larger feature requests require more careful evaluation and prioritization.

For example, if Product Team A requests a new capability—automating the export of customer data from a CRM system to their analytics dashboard to streamline reporting—it’s unwise to jump in and build it immediately without first assessing the trade-offs and determining what other work might be deprioritized.

Consider allocating around 50% of the team’s resources to a dedicated stream for such requests.

Evaluate the impact vs effort for these requests.

For example,

• If the feature directly supports a high-priority objective (OKR) for the current quarter, it should be classified as high impact.

• If the feature doesn’t align with immediate objectives but would significantly simplify workflows for multiple teams, it can be considered medium impact.

• Features with limited or niche benefits could be deprioritized and treated with low impact unless their value becomes more apparent over time.

How you evaluate impact will depend a lot on your organization’s dynamics and any agreements or strategies established at a higher level.

Effort estimation doesn’t need to be precise. Simply categorising requests into high, medium, or low effort is usually sufficient for prioritization.

Make prioritization transparent.

Use impact and effort as the primary parameters for prioritising requests. Let these parameters be the drivers, but allow for some flexibility and ideally, make the prioritization transparent and aligned with the relevant stakeholders (see bellow in Step 3)

Stream 3: Internal Improvements and Strategic Platform Initiatives

These initiatives are typically platform-driven objectives aimed at improving scalability, reliability, or reducing technical debt. Automating deployment pipelines, refactoring codebases, or performing code cleaning are examples of this category.

It's important to allocate time for this work. Regular maintenance and code optimization often require 15–20% of the team’s capacity. Occasionally, larger initiatives, such as migrating to a new modern framework, may become a priority for the upcoming quarter, demanding a more significant allocation of resources.

Consistently dedicating effort to these improvements helps mitigate the risk of accumulating technical debt and prevents the gradual decline of the platform team's productivity.

Step 2. Track Workload and Observe Inefficiencies

Categorising work into streams makes tracking way easier and helps identify patterns that may require intervention.

• Is each stream receiving the attention it needs?

• Can you keep up with the pace of requests?

• What is the throughput for each stream?

A common imbalance occurs when high-priority ad-hoc requests (Stream 1) consume the majority of the team’s time, leaving little to no capacity for long-term improvements.

These insights can be invaluable for refining the model, revisiting priorities with other teams, redistributing capacity, or identifying areas that may need additional investment.

Monitor the flow of work within each stream. It’s also useful to build simple dashboards to track progress per stream and make these available to other teams.

Step 3. Establish Shared Governance

To ensure transparency and alignment across teams, it’s essential to establish a shared governance model.

This can take the form of regular meetings (e.g., bi-weekly or monthly) involving representatives from both product and platform teams, as well as global product leadership. These meetings provide a forum to:

• Share progress and communicate any relevant changes in capacity allocation. When important - provide insights to justify these decisions.

• Discuss trade-offs and resolve conflicting priorities.

• Identify under-resourced areas and bottlenecks in the process and adjust upcoming OKRs accordingly.

• Adjust the prioritization framework based on observations of inefficiencies or bottlenecks.

When Prioritization Isn’t Enough: Alternative Models

Sometimes, even a solid prioritization framework isn’t enough. In such cases, you can consider alternative collaboration models: open-source contribution model and embedding platform engineers in product teams.

These models often blur the boundaries of platform ownership, shifting some responsibilities away from the platform team. While they do come with their drawbacks, they can be viable in situations where managing inter-team dependencies is critical, and time constraints are significant.

The Open-Source Contribution Model

The open-source model enables product teams to contribute directly to the platform codebase, with the platform team acting as reviewers and approvers.

The benefits of this model are clear: it scales development by distributing the workload and empowers product teams to take ownership of the tools they rely on.

However, this approach also introduces risks. The platform team no longer retains full ownership of the platform. They must establish clear contribution guidelines, maintain comprehensive documentation, and follow a rigorous review process. Without these safeguards, the platform can quickly become disorganized and difficult to manage.

This model is also not effective when the platform team serves as a specialized team such as a Center of Excellence with deep expertise in areas like Salesforce or CRM. If the product teams lack this specialized knowledge, they would be unable to contribute effectively.

Embedding Platform Engineers in Product Teams

In this model, a platform engineer temporarily joins a product team to help them with work that requires platform change.

The primary advantage of this approach is speed and direct collaboration. By working side-by-side, the embedded platform engineer gains understanding of the product team’s requirements and can focus their efforts on addressing these needs.

This model also comes with trade-offs. Embedding engineers pulls them away from their core responsibilities, potentially slowing progress on strategic platform objectives. Additionally, prolonged embedding risks platform engineers losing focus on their specialized skills and expertise.

This model is designed to be a temporary arrangement. Overusing it defeats the purpose of maintaining a specialized platform team, as it dilutes the team’s focus and strategic value.

Tips on Tooling

We don’t dive deep into tooling, but if you’re using Jira, the Atlassian stack can offers solid solutions to streamline prioritization. Here are some key features and tools to consider:

• Categorization with Jira Boards: Using standard Jira boards with labels or tags you can categorize tasks by streams. This makes it simple to filter and track progress per stream.

• Jira Service Management (JSM) for Ad-Hoc Requests: For high-priority support or maintenance tasks, JSM can act as a centralized intake system.

• Jira Product Discovery for Feature Requests: Feature ideas or larger initiatives can be managed through Jira Product Discovery, a tool designed to align requests with organizational goals. It can support impact/effort evaluation and prioritization.

• Dashboards for Transparency: Jira’s dashboards can provide real-time insights into workload, task progress, and capacity usage. Tracking the right key metrics, can help you gain quickly insights, foster better communication and data-driven decisions.

Final Thoughts

Platform teams are the foundation of many organizations, enabling product teams to work more efficiently and autonomously.

Though they often operate behind the scenes, the quality of their work is critical—not only for the success of product teams but also for the entire organization.

To be effective, platform teams must prioritize wisely, finding the right balance between immediate needs and long-term goals. By maintaining transparency in their processes, they can foster a more effective product organization and create happier, more productive teams.

How is your organization supporting its platform teams? What strategies have worked for you? Share your thoughts!

Enjoyed this read? Subscribe to Lean Product Growth for regular updates on building and scaling a successful product organization.

Subscribe now

Access more product growth content on Lean Product Growth

Hiring the first Product Manager can be a game changer for a product company, but deciding when to make that hire often presents a dilemma.

In this article, we’ll explore:

▶️ Why hiring your first PM is a tough decision

▶️ Examples of when other successful companies have hired their first PM

▶️ Key indicators that suggest it is time to bring in a PM

▶️ How to set your new PM up for success

Why Hiring Your First Product Manager is a High-Stakes Decision

Hiring the first product manager can be a tough decision.

One reason for this is that the value of the product management (PM) role can be hard to quantify. A new sales role directly generates revenue, and engineering is essential for turning ideas into real products. That’s why in organizations with tight budgets, it’s often tempting to prioritize roles like sales to directly drive revenue, or engineering to expand development capabilities.

Yet, as McKinsey highlights, for any company where software is central to growth, product management is one of the most critical functions.

A PM reduces the time it takes to deliver value to customers. They act as a vital link between customers, engineering, and the business to align product strategy with user and company goals.

That said, PMs play a pivotal role in the long-term success of a product. Their real value emerges as you begin to shift your priorities towards extended and sustained growth.

When to Hire Your First Product Manager? Insights from Successful Companies

In recent research, Lenny’s Newsletter analyzed 30 successful companies to understand the stage that each brought a product manager in.

On average, product companies brought on a PM with 10 to 15 engineers and 15 to 25 total employees. However, there was significant variation. For example, some hired a PM in the company’s first year, while others in the seventh year, when the company had roughly 100 employees and 30-50 engineers.

For the companies who hired later, the reasons for delaying varied. Stripe waited five years because it prioritized hiring highly skilled, product-minded engineers who could handle both engineering and product responsibilities. Others delayed because it took longer to achieve product-market fit.

On the other hand, companies that hired a PM early, often did so because they lacked the skills or time to effectively manage the product function themselves.

6 Signs It’s Time to Hire a Dedicated Product Manager

In early-stage startups, someone naturally takes on product management responsibilities, often without formally realizing it. Typically, this falls on the founder, CEO, or sometimes the CTO.

In the beginning, this setup works—especially before product-market fit is achieved, when the product is still evolving. However, as the company grows, the roles of the CEO or CTO expand. Juggling product management with these added responsibilities becomes increasingly difficult.

Here are the six key signs it’s time to hire a dedicated PM:

Your team isn’t shipping high-value features

This is a major indicator that prioritization needs improvement.

Review your team’s demos or release notes. Are the features you ship the ones that deliver the most value?

Evaluate the product. Do you notice any low-value features? Would omitting these features negatively impact the business? What does the data say?

If a team of five engineers is shipping 20 percent of features that aren’t providing sufficient ROI, a budget for hiring a PM can easily be justified.

Decision-making bottlenecks

Without a dedicated PM, decision-making can slow down.

If teams are constantly waiting for the founder’s input or if there’s no clear decision-maker, key decisions pile up. This leads to decreased productivity and missed opportunities. In some cases, poor decisions stem from a lack of full context, further affecting the product’s progress.

Talk to your team. Are they frustrated by the speed of decision-making? If so, it may be time to bring in a PM to streamline the decision-making process and keep things moving efficiently.

Overloaded teams with too many high-priority requests

When prioritising is challenging and not all requests can be met, expanding your team might sound like the best solution. But before making new hires, ask yourself: Is there someone who can objectively assess the ROI of these requests? Is there a system in place to prioritize them and identify low-value tasks that don’t pose a risk to the business?

A dedicated PM can implement a clear prioritization framework, helping to balance competing demands and maximize ROI. With clearer priorities, the pressure on the team also decreases, improving overall efficiency.

Inconsistent and incohesive product

When product management is spread across different roles, misalignment becomes a major issue. Conflicting priorities, a lack of unified vision, and fragmented ownership create an incoherent product strategy that eventually shows in the final product.

Examine your product. How clear and usable is it? Are the features aligned and in the right place? Is everything cohesive and consistent? Are you constantly reworking features due to incomplete context or suboptimal decisions?

Reworking features wastes time, drains resources, and frustrates the team. If your company is experiencing these issues, it’s a sign that you need a PM.

Launching a new product

If your company is expanding its product portfolio, launching a new product will likely require a dedicated PM. Tasks like customer discovery, interviews, competitive analysis, and MVP prioritization are essential during this phase. It’s crucial to set the foundation right to minimize the potential for rework later on.

While founders often manage these responsibilities for the first product, adding new products to an established portfolio requires someone with PM expertise and dedicated time to guide the process and prevent costly rework.

Unclear product strategy

Talk to team members, especially those involved in decision-making about which features to build. Do they have a clear understanding of the product strategy? Can they assess the value of a new feature? Do they understand the product’s competitive advantage?

If you’re getting inconsistent or vague answers, it’s a sign that more time needs to be spent refining and communicating the product strategy.

How to Set the New PM up for Success

Hiring for a new role, especially a PM, can be tricky and requires careful consideration.

You likely don’t have the experience to compare good versus bad candidates, there’s no clear blueprint for key responsibilities and goals, and there’s no predefined career path for the new hire.

That said, ensure the following factors are in place to give your new PM the best chance to succeed:

Define the role clearly

Take the time to clearly define the role. The responsibilities of a product manager can vary greatly depending on the company’s stage, industry, and needs. It may involve strategy, execution, market research, user experience, and more.

Ensure strong leadership alignment

Ensure the new PM understands the vision of the company founders.

This is an opportunity for the PM to help foster a product-centric culture. Is this vision aligned with leadership? If the first PM isn’t on the same page as leadership, it can lead to miscommunication or conflict over product direction.

Set balanced accountability

Hiring a PM shouldn’t come from the desire for the founder to focus on vision and strategy while the PM handles all the grunt work. If this is the case, it will be a poor deal for the new hire.

On the other hand, completely handing over the product without maintaining involvement is also problematic, as it can signal that leadership doesn’t view the product as important or strategic.

Seek the right qualifications

A PM role requires many qualifications, such as strong communication, technical knowledge, strategic thinking, and leadership skills.

However, the first PM needs more than that. They must be comfortable building from the ground up. This means handling both the high-level product vision and the granular day-to-day execution.

Finding someone who can balance both is often a challenge, so take the time to find the right fit.

Choose the right level of seniority

The level of seniority depends on the company’s stage. In very early-stage startups, where the founder has product skills and remains closely involved, it might be fine to hire a more junior PM who can grow over time.

However, at the stage where the founder is ready to hand off product management and soon build a product team, you need to hire someone with at least five to six years of experience in a similar role.

Hiring someone too junior may result in a lack of skills to drive the product strategy effectively. On the other hand, hiring someone very senior may also be challenging, as they might struggle with the hands-on work needed during the early phases.

Final Thoughts

There’s no one-size-fits-all answer for when to hire a PM. Every company has unique needs, and the right timing depends on your stage of growth and the specific challenges you face.

Reflect on the current obstacles you’re encountering due to the absence of this role. Can hiring a PM address these issues? Will the addition create enough value for the business, both in the short term and long term?

Getting the timing right is important. When your company is ready to scale, a PM can help you elevate both your product and business to the next level.

Originally published at https://blog.logrocket.com/ on Oct 14, 2024.

Access more product growth content on Lean Product Growth

Scaling sounds impressive and desirable. It signifies a company's success, indicating that it has found product-market fit and is now on a positive growth trajectory.

But scaling is not easy. Behind the signs of success lie significant challenges, and navigating these effectively during this critical growth phase is crucial.

A study conducted by Inc. Magazine and the Kauffman Foundation evaluated 500 of the fastest-growing private companies in the U.S. The study concluded that two-thirds of these companies had shrunk, stagnated, or failed after five to eight years, primarily due to premature and uncontrolled growth. In fact, the fastest-growing companies performed worse compared to their counterparts who followed more steady and controlled growth.

This does not come as a surprise. When a company is on a high-speed growth path, even a small misstep can have a huge, sometimes fatal impact.

Understanding Scaling

There is a subtle difference between growth and scaling.

Growth involves linearly increasing company revenue along with investments in capital, personnel, or technology.

Scaling, however, focuses on boosting revenue while minimising proportional increases in internal investments.

This distinction makes scaling particularly appealing. Software product business models promise scalable economics. This drives many companies to eagerly pursue the scaleup stage due to its financial advantages.

Scaleup is a Different Journey than a Startup

Scaling introduces its own set of risks, but that doesn’t mean you should avoid it. What's crucial is to understand what you’re entering and to approach it wisely.

First and foremost, scaling requires a shift in mindset that is different from running a startup. This demands new ways of thinking, different working behaviours, and acquisition of new skills.

As a scaleup leader, you should embrace your new role and be ready for the changes ahead.

People and Culture

People drive the company forward. They shape the company culture.

As your team grows, it’s crucial to focus on how you hire and how your culture evolves.

• Hire for evolution

Recruit individuals who not only fit your current culture but can evolve it.

During the startup phase, you’ve likely built a culture you're proud of, perhaps characterised by flat hierarchies, strong team bonding, creativity and innovation, risk-taking, and maybe long working hours.

While you’ve been hiring like-minded individuals to fit this culture, now it’s important to bring in people with fresh perspectives who can help adapt and evolve the culture.

This doesn’t mean abandoning your core values; they should remain steadfast. However, as your company transitions from startup to a more mature organisation, your behaviours and practices should naturally adapt and change.

• Innovators, accelerators or maintainers

In a startup culture, innovators excel. They are the people who propel the company to the next level. But innovators can be a terrible fit to enable effective scale.

Scaling is about building systems that are repeatable and scalable - systems encompassing people, processes and technology. This demands different skills and mindset, it demands accelerators.

While innovation thrives on divergence, the scaling phase necessitates convergence—bringing together diverse ideas, reducing noise, prioritising effectively, and constructing robust, repeatable systems capable of scaling.

And once these scalable systems are established, maintaining them requires maintainers - individuals with a diligent focus on stability and efficiency.

Keep an open mind and before you hire, think about what role you need - an innovator, accelerator, or a maintainer.

• Be prepared for less commitment from new hires

When your startup consists of just a few employees, everyone is fully committed to the mission of your company—emotionally, time-wise, and perhaps even financially.

As the company grows, you can’t expect the same level of personal investment from new employees. This shift is natural and reflects healthy growth.

Be prepared for these changes. Consider how to adjust policies and remain competitive in attracting top talent.

• Empower teams and let go of control

Founders, often natural innovators, may struggle with the mindset shift required as their startup grows. Some successfully transform themselves and lead the company through its entire journey from a startup to a large enterprise. However, this transformation demands readiness for a personal change.

Leadership in a startup requires deep involvement in details. Startup leaders make crucial decisions—from acquiring new customers to integrating new technologies into the software architecture.

Attempting to maintain this level of control as the company scales is unsustainable. It harms teams, impedes progress, and creates decision-making bottlenecks.

Godard Abel, the founder of five successful tech companies, shares his personal experience with the challenge of letting go of control:

Put on your new hat of a scaleup leader. Focus on assembling the right team, share your vision, align on the right goals and empower teams.

Let go of control.

Operations and Technology

Without scalable processes or technology in place, the risk of failure is high. Overburdened teams and operational bottlenecks can quickly overwhelm your company and strain your budget.

This phase demands optimising your operations and technology, eliminating the waste before you scale.

• Funding for scale

Building scalable systems is an investment.

During the startup phase, you likely didn’t implement fully scalable systems. Technical decisions made earlier may now be costly and hinder your growth.

With focus solely on growth without investing in scalability, significant improvements will be unlikely.

Securing adequate funding and planning for scalability is required. True, this doesn’t directly bring in revenue, but is crucial. Not only does it keep your margins healthy in the long run, but it also mitigates the risk of overwhelming your team and collapsing your systems as you scale.

• Scalable processes in every part of your organisation

In the scaleup phase, solving a problem once isn't enough. It's about reducing or eliminating the problem the next time it occurs.

Every department— sales, HR, technology or customer support—must operate with scalable processes. Standardising procedures, investing in the right tools, automating repeatable tasks, and continuously evaluating and optimising workflows are essential. These practices help maintain consistency and efficiency as you expand, making growth manageable.

Take the customer support department as an example. Initially, handling inquiries via email might suffice. However, as the company grows, this approach becomes inefficient and slow. Implementing a scalable solution like a ticketing system, combined with AI-driven chatbots, can be the way to improve team productivity and maintain high customer satisfaction.

• Scalable technology

Wrong technology choices made in the past can harm your business as you scale. 

Non-scalable software architecture can create bottlenecks, limit performance, and significantly increase costs. You may hit these boundaries at the least desired moment, risking customer satisfaction and causing employee burnout.

Making substantial changes in technology and architecture can be expensive and time-consuming. This can be a painful reality, but waiting only worsens the problem and increases the technical debt.

Addressing these issues as soon as possible is the best way to avoid escalating costs and operational disruptions.

Organisational Design

Scaling introduces complexity in team dynamics and responsibilities. As your company grows, a clear governance model becomes essential to manage this complexity effectively.

• New specialised roles

In the startup phase, responsibilities are often spread across multiple domains, with employees—especially leaders—juggling various roles. This approach becomes unsustainable as the company grows, leading to bottlenecks, diluted focus, and lower quality work.

It's time to begin hiring for specialised roles. However, don’t rush this process, as moving too quickly can be detrimental and costly.

Prioritise initiatives that are critical and currently lacking attention. Assign a dedicated person to drive these initiatives. This role could also be filled internally, but ensure the assigned employee has freed up her schedule and can be committed to this new focus.

• Scalable team structure, more accountability

Is your team already large but lacking clear structure and accountability? Now, imagine the complexity of adding 10 more people to the mix.

Effective growth demands a well-defined team structure. To scale successfully, design your organization by creating smaller teams with clear purpose. Start by identifying key domains within your team and assigning dedicated roles to focus on each area, while minimizing dependencies between them.

Each high-performing team should have a clear focus, purpose, and accountability—this can significantly boost productivity.

Key Takeaway

If you have reached the scaling stage— congratulations, it's an amazing achievement!

Scaling is the next exciting journey filled with new lessons and challenges. It’s more than just growth; it requires strategic planning and adaptation. Prepare for changes - new approach to hiring, redesigning your organisational structure, or optimising your processes and technology.

Most importantly, this phase demands a shift in mindset across the whole company. 

Build a lean and scalable system of people, technology, and processes, and embrace the scaling journey with confidence.

Originally published at https://www.mindtheproduct.com/ on Sep 10 2024.

Enjoyed this read? Subscribe to Lean Product Growth for regular updates on building and scaling a successful product organization.

Subscribe now

Access more product growth content on Lean Product Growth

Is More Headcount Necessary? How and When to Scale a Team?

How the Over-Promise and Under-Deliver Strategy Pushes Team Performance

How To Structure Teams That Effectively Execute Product Strategy

Building a product presents unique challenges for every company. Given the varied tech landscape, it's no surprise that approaches to product management differ significantly from one organization to another.

The contrast between managing products for the consumer market and those for the enterprise sector is particularly striking. Factors such as business models, user access, and customer expectations all play a crucial role in shaping how product management is defined and executed.

In this article, we delve into the complexities of Enterprise Product Management.

To provide deeper insights, we discussed with Deepak Deolalikar, a seasoned product advisor with over 14 years of experience, particularly in the enterprise space. Our discussion highlights:

• The core differencies of enterprise product management

• Key challenges and common pitfalls faced by enterprise product managers

• How to drive product adoption in the enterprise sector

Deepak’s Journey: From Software Programming to Enterprise Product Management

Deepak’s summirizes his career in several phases.

“After graduating, I started as a computer programmer, initially aiming to be a chip designer but quickly shifted to developing ERP software, CRM systems, and financial accounting tools, building products for small and medium-sized manufacturers.”

Deepak then moved to the U.S. and joined KPMG. “I worked with large clients like Microsoft or Expedia, but consulting didn’t really align with my goals,” he recalls. At that time he finished his MBA at Berkeley. Inspired by his professor Steve Blank's teachings, Deepak joined a startup as the second employee. “It was an intense experience but taught me a lot about resilience and how to build a product for an enterprise customer.”

In 2015, he joined SugarCRM, where he launched four different products. “The shift from a startup to a company with 400 employees was significant, requiring me to adapt while driving innovation,” he says. After leaving SugarCRM, Deepak was recruited by Brightedge to build a new marketing automation product which went beta with 25 customers. Since 2023, Deepak has focused on teaching, coaching, and advising in product management, particularly in the B2B enterprise space. He has advised 10 startups and coached 150 PMs. 

What is Enterprise Product Management?

“Enterprise Product Management involves creating and managing products designed for large organizations. That means your target market is businesses, placing you in the B2B (Business-to-Business) space, with a focus on meeting the needs specifically of larger enterprises,” explains Deepak.

Here are some key examples:

• Salesforce: As a CRM (Customer Relationship Management) system, Salesforce helps businesses streamline their sales and marketing processes.

• SAP: SAP provides a suite of Enterprise Resource Planning (ERP) software that assists organizations in digitizing and managing their finance or logistics business operations.

• Workday: Workday is primarily an HR management enterprise software solution. It helps large organizations effectively manage their workforce and HR processes.

• ServiceNow: ServiceNow is another product that supports enterprises in managing their IT operations or incident management.

While these products are not exclusively used by large organizations, they are primarily designed to address the complex and unique processes of enterprises.

What are Key Challenges of Enterprise Product Management

Deepak mentions several key challenges that are specific for enterprise product management.

Heterogeous nature of the products

“Every company operates differently, even within the same sector. For example in financial accounting, there are 14 methods of depreciation calculation just in the United States. This variability makes it incredibly challenging to build a one-size-fits-all product for B2B enterprises if you are building a financial software. 

While there are exceptions, with some products like e-signature, or calendar management, where the processes are more or less the same in any organisation, the typical enterprise product, like CRM or ERP system requires a much more nuanced approach.”

Risk and Business Continuity

“Large enterprises are particularly concerned about risk—business continuity is critical,” says Deepak.

He cites the example of a recent CrowdStrike meltdown, which led to one of the biggest IT outages in history. “Large enterprises cannot afford such disruptions,” he emphasizes. “In contrast, small to medium-sized businesses (SMBs) may be more willing to take risks if the potential ROI is high. But an enterprise would rather choose not to use any product than risk their business continuity.”

Change management

Change management is another significant challenge in the enterprise space.

“It’s easier to change habits in a small business, but in large enterprises, with thousands of users and complex workflows, implementing change is much harder,” Deepak notes. “Integrating your product into the natural workflow of your customer and users is a challenge and requires careful change management.”

Integrations with other systems

Integration with existing systems is also a critical factor that makes product management challenging.

“Enterprises often have dozens of interconnected systems, so any new software they introduce must fit into their ecosystem,” Deepak emphasizes. This need for seamless integration is a key consideration in enterprise product management, where new products must effectively integrate with other systems.

What are Common Mistakes in Enterprise Product Management

Deepak mentions two common pitfalls in enterprise product management.

Underestimating the complexity of customer needs

One of the biggest mistakes companies make, according to Deepak, is underestimating the complexity of their customers’ needs.

“If you’re building for large enterprises, you need to understand every aspect of your customer’s business and industry,” he advises. This deep understanding is crucial for creating products that can adapt to diverse business practices.

Underestimating the Need to Manage Customer Input

Another common challenge is how companies organize to manage customer feedback.

“Enterprises often require more hands-on assistance, not just from customer support but also from product teams,” Deepak says. “When your customers are using the product, you’ll receive a lot of feedback from customers, and managing it effectively is a significant part of the role,” he adds.

“When I was at SugarCRM, we used to handle around 4,000 support tickets every month. Half of them were product-related—questions about how the product works or issues within the system. That’s a substantial amount of input to manage.”

How to Balance Configurability and Complexity in Enterprise Products

One of the technical challenges in enterprise product management is finding the right balance between configurability and complexity. “You have to strike a balance between extreme configurability and keeping the product simple,” Deepak explains.

To address this, Deepak suggests standardizing the most common use cases while allowing for customization where necessary. “The key is to make the majority of your customers’ experience straightforward while offering advanced options for those who need them,” he advises. “It’s like offering vanilla ice cream versus 57 flavors—too many options can lead to decision paralysis for customers.”

This approach helps manage complexity while still providing the flexibility that enterprise customers often require. “It’s about finding that middle ground where you can satisfy the needs of most customers without overwhelming them with too many options.”

Why is Feature Adoption Usually Lower in Enterprise Product Management?

In enterprise product management, it’s crucial to understand that not every feature is meant to be used across the entire user base. "Enterprise requirements are highly heterogeneous," highlights Deepak. “For instance, a feature that allows customization of tax rates on invoices might be critical in Europe, where tax regulations vary significantly by country, but irrelevant in other regions like India. This means that certain features are only intended for specific segments of your customer base.”

Evaluating feature usage correctly is key—if only 2% of your total customer base is using a feature, you need to consider whether that feature was designed for everyone or just a targeted segment.  If it was meant for 20% of users, an overall 2% adoption rate could really mean 10% adoption. Understanding the denominator is important. “

“When a feature isn’t adopted as expected, it’s important to explore the reasons behind this, and then to address it properly. There are several possibilities for low adoption.

• The feature wasn’t truly needed, which suggests a failure in the initial discovery or validation process.

• A lack of user priority. In large enterprises, there are often numerous competing priorities, and your new feature might not be at the top of the list. In an enterprise with 47 priorities, your feature might be priority number 37—important at some point, but not at the moment.

• Lack of awareness. Many features in enterprise products get lost in the complexity of the system. Continuous communication, training, and reminders are essential to ensure that customers are aware of the features available to them and understand their value.

• Difficult to use. The customer may have tried the feature, but if the flow is not effective and it doesn’t simplify their work compared to alternative tools or no tools at all, adoption will be low.

It’s crucial to first gather feedback, identify the root causes of the low usage, and then make necessary adjustments in the feature or the overall process of how you build features.”

How Much is Measuring Product Usage Important in Enterprise Product Management

“The expectations for product adoption differ between B2B and B2C.

In B2C, high adoption rates are critical because consumer products often live or die by how widely they are used. For enterprise products, while adoption is important, the primary focus is on whether the product delivers true value to the business. It’s more important to ensure that the product meets the critical needs of the business, even if certain features aren’t used frequently. What matters most is that the product is solving real problems and providing tangible benefits.”

However, measuring product adoption is critical, both for B2B and B2C. But many product companies who build for the enterprise customer are not as mature in this area as they should be.

“At SugarCRM, we had zero product measurement when I first joined,” Deepak admits. “We had no idea how many users were logging in or what features they were using.”

“Enterprise product management companies should be much more thoughtful about why they want to measure adoption and then instrument it to measure effectively,” he advises.

How do You See the Future of UX in B2B Products

Enterprise products are known for their complexity and often lower usability compared to consumer-oriented products. Consumers have much higher expectations; if something doesn’t work properly, they would easily easily switch to another competitor.

“My manager once asked me, ‘Do you have a manual for Facebook?’ No, I don’t need it,” Deepak recalls. “Then why do we have a manual? Well, we can’t avoid it—our product is complex.”

Deepak acknowledges a positive trend toward the consumerization of B2B products over the past decade but remains skeptical about how closely enterprise software can emulate consumer products like Facebook or Google. “While the idea of making B2B products as simple as consumer apps is appealing, the reality is that enterprise software serves much more complex needs,” he explains.

“The complexity of business processes is reflected in the products designed to manage them. While there are definitely opportunities to simplify certain aspects of enterprise software, Deepak believes that the inherent complexity of business operations will necessitate a level of sophistication in the tools that support them.”

What is Your Advice for Product Managers

As a final piece of advice, Deepak stresses the importance of seeing product management as a business role, not just a technical one.

“If you think a product manager’s job is to create stories, epics, do some testing, and then hand off the product, you’re not a product manager—you’re a delivery manager or a product analyst,” he says. “Your job is to go broader.”

He advises product managers to think holistically about their role.

“Ask yourself: Who is my customer segment? What are their main jobs to be done? What are their key pain points? How are they solving these problems today? What can they not do today that my product should enable?” he explains.

He also emphasizes the importance of continuous learning. “Don’t just focus on PM-specific courses. Learn about economics, business strategy, pricing, accounting, and finance. These are all critical to understanding the broader business context in which your product exists.”

Connect with Deepak

We thank Deepak for this insightful conversation.

If you want to connect with Deepak and explore more of his insights into Product Management, check out his writings on B2B Products OS Newsletter. Or reach out to him on Linkedin.

He also offers a 3 day bootcamp for early stage startups to get started and get to first 5 paying customers. Check for more info: www.businessofproducts.com.

Enjoyed this Article?

Subscribe to Lean Product Growth for regular updates on building and scaling a successful product organization. Don’t miss out on insights, strategies, and actionable tips—delivered straight to your inbox.

Lean Product Growth

For leaders aiming to build scalable product organizations. Discover insights on crafting scalable products, leading growing high-performing teams, and elevating your career.

By Marina

In my previous article, we explored the benefits and risks of outsourcing product development.

Now, we’ll take a step further. How to set up a successful product development team and which roles are best suited for outsourcing versus those that should remain in-house.

True, there’s no universal answer—it depends on factors like your development stage and unique business needs. But by evaluating the options and weighing the pros and cons for your specific situation, you can make an informed decision and increase your chances of success.

In this article, we'll cover:

✅ The essential skills for a product development team

🔒 Which roles to outsource during MVP product development

🔒 Which roles to outsource when scaling from MVP to a mature product

🔒 Which roles to outsource when software becomes a strategic asset

🔒 Outsourcing Non-Core Activities

Key Skills in a Product Development Team

A successful product development team requires a blend of essential skills, each playing a crucial role in the product's success. Here are the key skills a product team should have:

Product management: This skill set might not always come with the title "Product Manager," especially in small startups where the founder often takes on this role. Product management involves owning the product vision and strategy, understanding user needs, and organizing product delivery to minimize the time required to meet customer demands.

UI/UX design: For user-facing products, proficiency in UX research, prototyping, and UX testing is crucial. The level of experience required depends on the project's complexity, the underlying third-party platforms used, or the user expectations in the specific domain.

Software engineering: This area often demands the most effort in product development. It covers software architecture, development, testing, and software maintenance. Software engineers ensure the product's technical foundation is robust and scalable.

Operations: This area involves responsibilities like infrastructure setup, and cloud maintenance, deployments management, all necessary for maintaining a reliable product and seamless development experience.

Quality assurance: Ensuring the product meets the highest standards of quality is vital. QA involves rigorous testing, bug identification, and ensuring the product functions as intended. This skill set is essential for delivering a reliable product with good user experience.

While this list highlights essential skills, the specific structure of your team may vary. It is not necessary to have a dedicated role to cover each of these areas. This depends on the scale and the skills of the team members.

Here is an example of how a team could potentially be structured.

With this framework in mind, let’s explore different scenarios and evaluate which roles in each case could be outsourced without posing a significant risk to product development.

Outsourcing for MVP Development

Read more

In product development, one critical decision you'll face is whether to choose outsourcing or in-house development for building your product.

Even adding a single new member to your team can have a profound impact on the team dynamics. Outsourcing amplifies this effect and can even be a determining factor in your project’s or product's success or failure.

This post answers some key questions about outsourcing:

🌟 What are the benefits of outsourcing software development?

⚠️ What are the risks and how to mitigate these risks?

🎯 What are example scenarios where outsourcing is a good strategic choice.

Key Benefits of Outsourcing Software Development

Outsourcing software development is a strategic tactic where a company engages an external organisation to manage some or all of its software development activities.

This approach can range from crafting a single application to overseeing the entire development lifecycle for multiple projects.

Some benefits of outsourcing are undeniable:

• Quick access to specialised skills: When you partner with a software development agency, you get more than just support with development; you also avoid the hassle of recruiting. This is especially useful when you need a team quickly for a new project, particularly for roles requiring specific expertise or advanced technical knowledge that your company may lack.

• Cost efficiency: Outsourcing can be a cost-effective solution, though this varies based on the agency and its location. However, it's not just about saving on development costs. Outsourcing also cuts down expenses related to recruitment, training or maintaining an in-house team, which can add up significantly over time.

• Flexibility to scale up and down: Consider a scenario where you're starting a new project that requires additional capacity but you don’t expect this to be a permanent expansion of your team. Outsourcing offers a practical advantage here, allowing you to expand your team temporarily and scale back easily once the project completes.

Risks of Outsourcing and How to Mitigate Them

Despite the significant advantages of this model, there are risks that should not be overlooked.

Risk 1: Low quality due to lack of accountability

When not managed carefully, outsourcing can lead to compromises in the quality of the final product due to miscommunications or differing standards. The responsibility here lies with both parties.

Often, software development agencies simply follow what the client requests. It's not uncommon to see software lacking quality standards, such as basic automated unit-level testing. When inquiring why such testing is missing, the typical response is that these were not specified in the requirements.

Mitigation strategis:

• Select a reliable partner: Choose an outsourcing partner known for maintaining high-quality standards that align with your project’s needs. If quality is ingrained in the external company's processes and culture, high-quality outcomes will naturally follow.

• Integrate internal roles: Include some internal team members in the external project team to maintain control over the project's quality. A balanced team with diverse roles and perspectives, both internal and external is good for better project health and quality visibility.

• Define explicit quality standards: Clearly define and include quality standards in the contract. This approach may not always be feasible, so carefully assess when it is appropriate. For external teams working fully independently, contractual quality standards can help ensure the software meets your expectations.

Risk 2: Differing interests leading to low productivity

Even the most trustworthy outsourcing partner will have different interests than your company. Your company's goal is to build a lean, high-quality product to minimize development effort and maximise value. Your partner’s interest might be contrary—more features mean more billable hours, and less automation and lower quality can also result in more development work.

Imagine you need to entrust key responsibilities, such as interviewing internal and external hires, to an external team member. Without having a trusted relationship, these tasks may not be handled fairly and objectively, leading to tensions and reduced productivity.

Mitigation Strategies:

• Trust and open communication: Start by selecting the right partner, one you can trust and who values long-term relationships and satisfied customers. Invest in the relationship through transparency and regular communication to build trust.

• Contractual alignment: Structuring the agreement to align the interests of both parties can also work well in some cases. Consider fixed-price contracts when the scope of work is clear, with clearly defined outcomes and high-quality standards. This discourages unnecessary feature creep and ensures both parties are working towards the same goals.

Risk 3: Limited influence on working methods

An outsourcing agency comes with its own working methods and quality standards. There won't be a lot of diverse perspectives within the team to bring new ideas. And isn't that the whole point of outsourcing—to delegate some responsibility and rely on another expert team?

This isn't necessarily a disadvantage in all cases, but it's something to be aware of. Influencing these methods can be difficult or even counterproductive. If you need to implement significant changes in your company and the way it operates, you might find this challenging.

Mitigation Strategy:

• Cultural integration: Facilitate workshops or joint training sessions to align methodologies. Make the external hires feel as being part of the team. Encourage knowledge sharing between team members, both external and internal.

• Strategic delegation: Clearly define areas where the outsourcing team has autonomy and areas where your company maintains control.

Risk 4: Over-reliance on a single outsourcing partner

If the success of your entire product or project relies on one outsourcing partner, this is a critical risk. Even with a great partner agency and excellent people, unforeseen circumstances could force you to terminate the contract, disrupting your project and endangering the continuity of your product.

The likelihood of this risk occurring might be low, but the impact is huge.

Mitigation Strategy:

• Hybrid Teams: Ensure knowledge is shared among both internal and external team members. Critical software components should not be solely owned by an individual or by the external team alone. While this might be necessary in some cases, it should be a temporary measure. The longer this situation persists, the greater the risk.

• Limit the Risk Duration: When exploring product-market fit for a new product, it’s common to rely fully on an external agency. However, as the product becomes a key asset for your company, it’s crucial to diversify the team. Integrate internal team members to reduce dependency on the outsourcing partner and ensure the continuity and security of your strategic assets.

Risk 5. Cultural and communication barriers: Differences in language and work culture can also pose significant risks. Additionally, if time zones are not aligned, the challenges increase, potentially leading to delays and low-quality outcomes. Outsourced teams can sometimes feel distant due to their external status, which can affect the dynamics of teamwork and execution.

Mitigation Strategy:

• Cultural compatibility: Choose partners with similar work cultures or those in similar time zones to ease communication.

• Team integration: Involve external team members in company events and regular meetings to encourage a sense of belonging and improve collaboration.

Risk 6. Security risks: Sharing sensitive information with an external party can lead to data breaches or leaks. True, the risk is the same for your internal employees, but outsourcing adds an additional layer of reliance on the security measures integrated by your vendor, over which you have limited control.

Mitigation Strategy:

• Security alignment: Ensure the outsourcing partner adheres to your company’s security protocols. Consider formalising this in your agreement.

• Regular audits: Conduct periodic security reviews and audits to ensure compliance and address vulnerabilities.

Ideal Scenarios for Outsourcing:

Let’s explore some example scenarios where outsourcing is a good strategic option.

When project requires specific expertise

Professional development services are inherently service-oriented rather than product-focused. They excel with clear requirements and milestones.

Consider, for example, a data migration project involving a complex software landscape. It requires specialized expertise beyond your team's training. Hiring an external party specializing in data migration could be advantageous. Naturally, there are challenges in integrating another team to learn your product, but none of the other scenarios in this case will be easy.

In situations with limited internal expertise and capacity

If you're a startup lacking the resources for a full-scale development team, outsourcing could bridge these capacity gaps.

For instance, imagine you're testing a new idea and need to build a small MVP, but lack the required expertise in-house. Outsourcing development could be a viable option, especially since the success of the product remains uncertain. However, it's crucial to select a development partner specialised in MVP development, as the approach differs significantly from traditional development methods.

When software isn't core to your operations

Consider a manufacturing company that wants to create a mobile application enabling its clients to track the production status of their orders in real-time but lacks a software development department.

Since this task isn't a core activity for the company (yet), outsourcing the mobile app development to a tech company enables the manufacturer to offer value-added services to its clients without diverting focus from its core competency in manufacturing.

However, even for a manufacturing company, digitalisation and tech products may become part of a new strategy. When this shift occurs, building an internal team would be a wise move. This trend is increasingly common for many non-tech companies.

When team dynamics are high

When there is a high dynamics in the team and the team needs to scale up fast, or potentially scale down tomorrow, outsourcing can also be a good option.

But here you need to be careful. Excessive dynamics can disrupt the entire team, regardless of whether outsourcing is involved. It's crucial to ensure that knowledge remains within the team, that product quality isn't compromised, and that the team's well-being is maintained.

Final thoughts

The choice between outsourcing and building an internal team remains pivotal. But the success depends not only on the decision itself but also on how effectively you manage these risks and you leverage opportunities.

P.S. Stay tuned for the upcoming article on this topic: How to choose the right roles to outsource?

One common question businesses face when planning a new product is whether to build the software from scratch or buy a commercially available software platform. This is an important decision that can significantly affect development costs and future risks.

Before discussing the best model to choose, let's first explore the common software models, including their benefits and drawbacks.

Custom development

Custom development or bespoke development is the traditional form of development when you develop custom-built software, tailored to your specific business needs.

Custom development includes the process of designing, implementing, deploying and maintaining software, and is built typically by in-house development teams or outsourced to a third-party. Some of the most popular programming languages for general-purpose custom software development are Java, C#, PHP, JavaScript, Python, etc. These are programming languages commonly used by software developers.

So what are the benefits and drawbacks of custom development?

High flexibility

With this model, there are essentially no limitations; you can build anything you can envision. Consider the analogy of purchasing a custom-made suit: you can design the model as you like, without limitations.

It does not mean that the entire software is built from scratch. Indeed, some third-party libraries can be utilized, but the software's foundation is custom-built.

Increased control

Custom software development means you are not heavily reliant on a third-party solution. The risk that a third-party will cease support or that you will encounter an issue with insufficient security implemented in the third-party solution is lower.

Greater Responsibility

However, with reduced reliance on third parties comes greater responsibility. It falls upon you to address any security, privacy, or compliance requirements.

Higher Initial Investment

Custom development demands higher initial development costs. Your team must navigate through the entire process of understanding customer needs, designing the product, developing, and deploying. This requires significant time and effort.

An Asset in the Long Run

The custom software you develop becomes an asset to your organization. As the product stabilizes, implementation costs decrease over time, making the software a valuable asset in the long run.

Commercial off the shelf (COTS)

On the other hand, we have Commercial Off-The-Shelf (COTS) platforms. Using a COTS model means that you're purchasing a commercially available platform that isn't built specifically for you but is designed for the masses. Since it's produced for a broad audience, COTS software adopts a "one-size-fits-all" approach, guided by general best practices. Typically, you'll need to make some adjustments to adapt the platform to your specific needs. This could involve configuring the platform or, if allowed, developing some custom software to tailor the platform further. Consider the analogy of buying a suit: you purchase the size that best fits you and then make minor adjustments.

Typical examples of COTS platforms include e-commerce platforms. E-commerce is a very common business model, and e-commerce applications often share similar functionality, e.g., purchasing a product, marking a product as a favorite, or adding a product to a shopping basket. Because this functionality is common across a wide range of applications, companies like Shopify, Sharetribe, and Magento have packaged it into platforms commercially available to many businesses.

The COTS model offers many benefits but, of course, also has drawbacks.

Faster Time to Market

Using a COTS platform means you don't have to build your software solution from scratch, allowing you to develop the product much faster, sometimes even within a few days. This enables you to bring a working product into production much quicker.

Limited Flexibility

For a COTS platform to be a viable option, it must offer the right functionality that fits your business needs. While some platforms allow for more customization, others offer less, but in any case, the ability to adapt the platform is limited.

Some platforms promise complete customization. However, even if you technically can make the product fit your needs, doing so may mean you are not leveraging the benefits provided by the platform, thereby making your product unnecessarily complex.

Long-Term Dependency on the Platform

Building a product on top of a COTS platform means you will heavily rely on the third party for aspects like security and performance. This leads to "vendor lock-in," as your product becomes fully dependent on a third-party platform. Moving away from that platform would likely mean rebuilding the software from scratch.

Long-Term Operational Costs

The long-term dependency on the platform also incurs continuous licensing costs over time. The pricing model of these platforms is often usage-based, meaning the more users your product has, the higher the cost. Thus, licensing costs will persist as long as your product is live and being used by your customers.

Often Less Performant Than Custom-Developed Software

This depends on the chosen platform and your specific needs, but generally, with this model, the software tends to be somewhat less performant, and achieving optimal performance is not as feasible as with custom development.

Custom low-code development

I would classify this as a distinct category. It refers to a type of commercially available platform that enables application building with minimal coding (low-code) or no coding at all (no-code). These platforms simplify the application development process by substituting textual coding with visual coding. Instead of typing code, you work with a visual interface and available building blocks. You can build your software application using a drag-and-drop method, reusing and connecting these building blocks.

While COTS platforms are sometimes also referred to as low-code platforms (because they reduce the need for software development), COTS are designed to meet the needs of specific groups of customers in certain domains (like e-commerce). The custom low-code development category, however, allows for the development of more generic-purpose applications but in a simpler way than traditional coding.

The benefits and drawbacks of this model are quite similar to those associated with COTS platforms.

Faster Time to Market

Low-code development can significantly boost development productivity, leading to a quicker product launch.

Increased Risk of Low Software Quality

Due to the minimal coding required, these platforms aim to make development accessible to non-technical individuals. However, this introduces a risk. Applications built by non-technical people using low-code platforms often become complex and of lower quality. Even with this type of development, understanding software concepts and best practices for structuring software is essential.

Limited Flexibility

Although these platforms suggest that they can be used to build any application, if the platform's available building blocks don't suffice, you might end up adding a lot of custom code. This increases your application's complexity. Thus, the functional flexibility of this model is limited compared to that of custom-built software.

Long-Term Dependency on the Platform and Operational Costs

Similar to COTS platforms, your low-code product is entirely reliant on the low-code platform. This results in ongoing licensing costs that persist as long as the software product is in use.

Often Less Performant Than Custom-Built

Low-code platforms typically exhibit lower performance compared to custom-built software. While this varies by platform, it's not uncommon for startups to begin with a low-code solution, only to encounter performance limitations and switch to custom-developed software as they scale.

When to build and when to buy

With this information in mind, try to answer the questions listed below and evaluate which model is best for your business at this stage.

Remember, there is no perfectly right or wrong solution. As long as you are aware of the risks and have found a way to manage them, you are on the right path.

Originally published at https://medium.com/geekculture

Ask several individuals within the organisation to share their key priorities. If you receive conflicting responses, it’s a strong indicator of a lack of a clear product strategy.

Product managers often find themselves pulled in different directions. Requests flow in from customers, sales teams, and various stakeholders. Everyone has an idea or an exceptional pressing question that need to be answered urgently. When prioritisation is a real struggle, it signals an absence of a clear product strategy.

What is a Product Strategy?

Product Strategy is a clear system of goals aligning teams towards desirable outcomes for both the business and its customers. It is a set of goals that moves the company closer to its vision, providing clear guidance on priorities.

The primary aim of product strategy is to unify teams, directing their efforts cohesively. Organizations with a well-defined strategy have clarity on key focus areas and their significance. They effectively communicate a clear strategic message, ensuring priorities are understood and embraced organization-wide. When everyone adopts these goals, integrating them into their individual scope, a shared vision emerges.

With a clear strategy, every team effort contributes to an important company objective. Without a strategy, teams engage in a multitude of actions without a clear understanding of the bigger goal, making prioritisation an impossible task.

Product Strategy vs Business Strategy

The distinction between product strategy and business strategy depends on the product's scope relative to the entire organization.

The business or company strategy encompasses the overarching organizational goals and a high-level plan for achieving them. It spans all aspects of the business, including the product and service portfolio, marketing, operations, and more.

In contrast, product strategy is focused on a specific product or line of products. It must align with the broader business strategy, essentially nesting within it.

In the context of a small startup with a single product central to the entire business, the product strategy may also be identical to the business strategy.

How to Create a Successful Product Strategy

A product strategy doesn't need to be a lengthy, complex 10-page document. It's not an exhaustive list of solutions to be built in the upcoming year. Instead, it's a straightforward, high-level plan outlining your key goals, what you'll work on to achieve those goals, and why.

While the end result should appear simple, creating a successful and simple product strategy involves a more intricate thinking process. Let's delve into the foundational aspects that contribute to a successful product strategy.

Vision and core values

Starting from the basics, a clear vision and core values have a direct impact on your strategy. They serve as the foundation for an effective product strategy, providing guardrails and guiding decisions.

For instance, Amazon's vision is to be earth's most customer-centric company, creating a space where people can discover anything they want to buy online. The core values, including customer obsession, passion for invention, commitment to operational excellence, and long-term thinking, further shape Amazon's core principles.

These guiding principles make it evident that the company's objectives should focus not on short-term business gains, but on long-term and enduring benefits for the customer.

Users and their needs

A robust product strategy builds on a thorough understanding of the target market or niche. Before establishing any goals, having a clear understanding of who the product is designed for is necessary. The aim isn't to create a product for everyone but to tailor it for a specific audience with shared desires and needs.

Understanding the niche goes beyond geographical, age, gender, or professional considerations. What is often more important is understanding their beliefs, passions, aspirations, and the areas they aim to enhance in their lives. This helps grasp how the product facilitates users in transitioning to their desired state and what concrete benefits your product offers to the users.

Product differentiators

You know the needs and desires of your customers. Should you aim to address all of them? Not quite. Rather than attempting to enhance every aspect of the product, a key element of the strategic framework involves honing in on the sweet spot.

Take, for instance, an e-commerce marketplace. Customer benefits might include the highest quality products, diversity of products, lowest prices, fastest delivery, optimal digital user experience, and high-quality customer service.

Striving to be the best in every category as a start isn't a sound strategy. While checking all the boxes is ideal, attempting to excel in all aspects simultaneously is risky. It's more effective to identify the sweet spot – what niche customers truly need, what the competitors can't provide, and where your strengths lie.

Understanding product differentiators means pinpointing the areas you want your product to be known for. This becomes your brand promise to the customer.

List down the benefits, and make an assessment, what are your competitors good at, and which are the key benefits that you will focus on.

Define the product strategic objectives

A solid product strategy rests on the foundation of vision, core values, user needs, and product differentiators. Once these essential elements are established, defining the objectives—integral components of the product strategy—flows naturally. Objectives serve as milestones on your path to achieving the vision, with core values and differentiators guiding and supporting the formulation of these objectives.

Product objectives are essentially derived from the broader company objectives, which are part of the company strategy. Product objectives offer a more concrete representation from a product standpoint.

Let's take an example:

Imagine a company operating an online shopping platform as its primary product. The overarching strategic objective for this year is:

Company objective: Boost annual recurring revenue.

The product team has introduced a subscription model, anticipating it as a catalyst for achieving this goal. However, data analysis uncovers a notable trend – a substantial majority of users are inclined towards one-time purchases, with only a fraction embracing regular subscriptions.

After talking to users, a major issue surfaces: some products have a significantly slow delivery time. The overall delivery time guaranteed by the subscription model exceeds what users find acceptable. The product goal becomes clear.

Product goal: Reduce delivery times.

To make this goal effective, it's crucial to also establish metrics and monitor progress over time.

Principles of a Strong Product Strategy

Every business and product has its own special traits and encounters unique challenges. So, creating a product strategy is unique to each situation, and you need to use your own judgment. However, there are basic principles that should guide the process of defining the product strategy.

High-Impact, mutually reinforcing elements

A successful product strategy centers on a selected few high-impact items that enhance both user satisfaction and contribute to your business success. Rather than attempting to do it all, prioritise wisely and make decisions based on key high-impact items. Ideally, these elements should be mutually reinforcing, working together to amplify the overall impact.

Customer first

Best product companies prioritise their customers, shaping the product vision around customer needs. They focus their goals on delivering customer value rather than solely pursuing financial gains.

For instance, a key product strategic goal could be to reduce delivery time for the customer. This objective doesn't solely focus on the financial benefit for the company but emphasises enhancing the customer experience.

Simple but strong message

A strong product strategy is simple — a straightforward and clear message that can be easily communicated across all teams.

Rather than relying on a lengthy and intricate document to explain every detail of the strategy, the power lies in selecting a high-impact goals and effectively spreading the message. The key is to have every team and every employee in the company embrace these goalas their own story.

Data informed

The goals you prioritise should be grounded in data. For instance, if you aim to enhance delivery time, ensure it's backed by concrete customer insights. Your data should reveal that delayed delivery is a significant obstacle for many users, impacting their trust and product selection.

Of course, solely relying on data isn't the complete solution; you must also apply your own judgment. But ignoring data is akin to navigating blindly based on assumptions.

Regularly revised

Creating a product strategy is not a one-and-done job but an ongoing effort demanding continuous review and enhancement. Set up a systematic process to regularly evaluate and refine the strategy. Revisit it on a quarterly or yearly basis. Continuous improvement is crucial to ensuring the strategy remains relevant and effective as time goes on.

A Strong Product Strategy Requires Great Execution

Crafting a robust product strategy marks just the initial phase of the journey. Achieving success relies equally on effective execution. The crucial element lies in translating the strategy into actionable initiatives, seamlessly integrating it with the unique roadmaps of each team, and ultimately linking it to their daily activities.

In the wise words of Morris Chang: “Without strategy, execution is aimless. Without execution, strategy is useless.”

Enjoyed these insights?

Subscribe now to get exclusive access to the full E-BOOK, “A practical guide on how to build a strong Product Strategy and achieve a Product-Market Fit”.

Subscribe now

Originally published at https://blog.logrocket.com on February 6, 2024.

A product roadmap is an essential tool for product managers and leaders. It is a high-level plan that maps out the product's evolution over a specific time period. It provides a sense of purpose, sets expectations, aligns stakeholders, helps prioritize tasks, makes budgeting smoother, and gives visibility to customers.

The product roadmap is a layer below the product strategy. While the product strategy explains on a high level how to achieve the product vision, the roadmap goes one level more in detail, outlining the What - what activities need to be done to make the strategy a reality.

However, in practice, creating an effective roadmap is often challenging. And a poorly executed roadmap leads to confusion, distrust, and misalignment, causing more harm than good.

So, how do you build an effective roadmap?

The problem with the traditional product roadmaps

Traditional product roadmaps are intricate, outlining a predetermined set of features tied to specific timelines, milestone dates, or release schedules.

While this structure may provide reassurance and optimism for everyone, it comes with significant drawbacks.

• Time, more often than not, proves to be inaccurate. A roadmap with specific dates would face challenges in execution, especially in agile development environments where predicting details months in advance is unattainable. Even with a well-prepared team ready for timely execution, external dependencies—such as delays in other teams or the provision of necessary data by customers—can disrupt the planned course of action.

• The delivery of a feature does not guarantee the desired outcome. Even if the predetermined set of features is delivered punctually, there is no assurance of achieving any desired impact. Why? Because realising outcomes often demands experimentation. Committing upfront to new product features (especially with fixed deadlines) transforms the team into a "feature factory" focused on timely delivery rather than ensuring that what they deliver makes a meaningful impact.

With these two drawbacks, the outcome is clear: over time the roadmap diverges significantly from the reality, and effort is being invested without visible business benefits. This creates confusion among teams, erodes trust, and leads to a loss of perspective on direction.

Outcome-based product roadmaps

The concept of an outcome-based roadmap is gaining more traction. Unlike traditional roadmaps, this method shifts the focus from detailing upcoming features to emphasizing desired outcomes.

The idea behind this approach is to keep teams focused on achieving meaningful results, aligning them around shared outcomes, and importantly, encouraging experimentation and learning. It instills a mindset where validation becomes crucial.

Features are crafted to drive outcomes. However, often, it’s only an assumption that a feature will drive the intended outcome. Before adding such a feature to the roadmap, it requires validation. Throughout its enhancement and development, continuous monitoring is recommended to ensure the right outcome is being achieved.

This is particularly true when a feature involves changing user behaviour. For instance, before adding a feature like an Interactive User Onboarding Tutorial to Increase User Engagement, teams must prioritise the outcome - in this case, increasing user engagement. They need to validate if implementing an Interactive User Onboarding Tutorial is the right approach. Once a basic version is available to users, observation and measurement of results become critical.

An important characteristic of Outcome-driven roadmaps is their advocacy for highly flexible timelines. One example is simplifying the timeline to a format without specific dates, categorising items into "NOW," "THEN," and "LATER,". This format highlights current key priorities (NOW), followed by subsequent items (THEN), and finally, ideas slated for the future (LATER).

In the real world, we might need elements from both.

Outcome-driven roadmaps are highly effective, and I strongly advocate for their adoption. However, it's crucial to pragmatically address real-world scenarios and understand what we need for our specific situation.

In practice, there are instances in the business world where specific dates are non-negotiable, such as achieving GDPR compliance or obtaining a security certification before an investment round. Decommissioning legacy software and migrating customers to a new platform may also be non-negotiable due to the end-of-life of a used legacy platform. Such cases warrant timelines with clear deadlines and concrete scope that need to be implemented.

While championing an outcome-driven mindset, incorporating elements from traditional roadmaps where necessary is not a problem, as long as we are clear about the rationale behind the choice and as long as we follow the principles defined below.

Key principles of an effective product roadmap

Developing an effective product roadmap requires a thoughtful consideration of a few essential principles.

Builds on top of the strategy: A solid company and product strategy is a prerequisite for a well-developed roadmap. A product roadmap should build on top of the product strategy and should clearly connect the product roadmap activities to the product strategic goals.

Provides context: A roadmap, as a communication tool, needs to be clear. It goes beyond listing tasks, answering the "why" to help everyone understand how the work fits into the bigger organisational picture.

Simplicity is key: A roadmap should use simple language, free of jargon that only your team understands. To be an effective communication tool, the level of abstraction should be in accordance with the audience.

Facilitates experimentation: A roadmap should incorporate experimentation and validation, avoiding the inclusion of features committed to build without proper validation.

Allows for adaptability: A roadmap should embrace the unpredictable nature of business. While short-term activities can be more specific as they are more predictable, it should maintain a high-level approach for the future, allowing for change and adaptation.

Follows an Iterative Process: A roadmap is not a one-time task. It should follow an iterative process, regularly refined and updated to ensure alignment with evolving strategies and organisational goals.

Steps to create a roadmap (with a template)

Now that we know what is a product roadmap, and what are the principles we need to follow when creating a roadmap, let’s outline the key steps of the roadmap creation process.

1. Decompose the company and product strategic goals

Start with the product strategy, which outlines key product goals and explains how they contribute to higher company strategic objectives.

Next step is decomposition. For each product strategy goal, generate a concrete list of initiatives relevant to the domain you are building the roadmap for. You can then map out the concrete activities associated to each initiative.

For example, if the company goal is to improve customer retention, the product goal is to increase user engagement, an initiative may involve enhancing the customer onboarding process, with activities such as simplifying the onboarding page or conducting customer interviews for more insights.

It is crucial to maintain an experimental approach. Add validated activities to the roadmap. If it's unclear which activities will be implemented, you can explicitly state that it's in the discovery phase. You can also include planned discovery and experimentation activities for transparency and planning.

2. Consider additional initiatives

You might be (or are planning to) working on activities not directly aligned with the strategic goals. For instance, the strategic goals may focus solely on growth, but your team might need to undertake complex software refactoring due to using a platform version that is approaching end-of-life.

Including these initiatives is crucial for transparency as it provides clarity to stakeholders on how your team will allocate their time.

3. Prioritise initiatives

Read more

Pivoting is a natural part of a company's growth.

It impacts startups that are in the search for product-market fit. However, well-established companies sometimes face circumstances that demand significant changes for survival.

Pivoting is a shift in the strategic direction of a business or a product, usually due to market, competitive or technology changes or shortcomings in the original strategy.

Pivoting isn't negative; it doesn't signal failure. It reflects a company's awareness and courage to change direction when necessary.

But the key is knowing when and how to pivot.

Done correctly, it can save a company and accelerate growth. But if mishandled, it can be a reason for a big failure.

The Need to Pivot Across the Product Lifecycle

Every product undergoes a lifecycle that typically follows a trajectory like this.

In the initial phase, the focus is discovering the product-market fit. Once that fit is established, the product transitions into a growth phase, followed by a maturity phase where a substantial market share is achieved. At some point in the lifecycle, the product may encounter a decline phase, prompting either a significant pivot or, in some instances, a product discontinuation.

Early Product Stage: Big pivots due to lack of experimentation

In the initial phases of a product, especially with startups, uncertainties are a given. Finding the product-market fit involves a series of tests, experiments, and adaptation. Pivoting is not just common but also necessary during this early stage.

This phase is all about experimentation. Once a goal is set as a hypothesis, it requires validation by implementing a few simple tests. If, after several repetitions, the approach doesn't yield the desired outcome, a pivot—a shift in direction—becomes a viable option.

Pivoting, when backed by data, seamlessly integrates into this journey. When integrated into a system of experimentation and validation, the pivots are small, ensuring a smoother trajectory in the right direction.

The issue arises when proper validation is lacking. This can lead to a significant gap between the product built and market needs. In such a scenario, changing course becomes costly, and a substantial amount of effort may be wasted because of persisting in the wrong direction for an extended period. Even more, recognising the need for a pivot later, without sufficient data, can be disorienting, leaving you uncertain about the direction to take.

Mature Stage: Big pivots due to lack of innovation

When a product enters the maturity stage, product market-fit is achieved, operations are more streamlined, and companies can reap the benefits with reduced efforts. However, a common pitfall at this stage is complacency— relaxing their focus and attention on the product and becoming unaware of potential risks.

But attaining product-market fit is an ongoing process. Market dynamics, user behaviour, competition, and technological advancements constantly evolve, sometimes much faster than expected.

Without sustained learning and innovation over time, companies may discover their product has become outdated, creating a substantial gap between their offering and market needs. The longer a product remains inert and stable, the more profound the challenges of transformation become. The consequence - the need for a significant pivot, which, with a mature product, entails substantial investment and high risk.

In recent years, numerous well-established brands that operated more traditionally encountered significant challenges due to technological advancements. They faced the need to undertake substantial digitalisation initiatives and modernisation of their technology portfolio. This shift was not easy, but necessary for them to survive.

Unpredictable need to pivot can happen at any time

Despite continuous validation and innovation, any company could still face the risk of substantial unforeseen shifts.

The COVID-19 pandemic is one great example. The impact on companies like travel agencies and sports clubs was huge; they faced the need for rapid adaptation.

Some companies leveraged this as an opportunity for accelerated innovation as a survival strategy, later enjoying long-term benefits. For example, some sports clubs quickly embraced the trend of digitising sports exercises, giving them a significant advantage even after the pandemic-related restrictions were lifted. But others who were not agile or hesitant to make bigger shifts were forced to shut down.

Sometimes, the unforeseen shifts from outside are so significant that a product cannot survive. The decline stage is a natural part of a product journey.

How to Stay Alert and Ready for Pivoting

Pivoting is an inevitable aspect of almost any company's journey. The best strategy is, therefore, to be prepared for necessary shifts.

1. Culture of Experimentation: The success of a pivot largely relies on people feeling confident about embracing change. That's why having a culture of experimentation is crucial. Companies that excel in experimentation have created a system that welcomes new ideas. They encourage employees to regularly try out and validate ideas, approving those that prove successful. In a culture where experimentation is the norm, people become more open to and accepting of changes.

2. Transparency: Leadership decisions, even when supported by data, should prioritise transparency. When a culture openly communicates the reasons behind a pivot, new decisions are much more welcomed. Transparency helps minimise hesitation and promotes the smoother acceptance of decisions.

3. Lean Mindset: Adopting a lean mindset is another factor that decreases the risk of costly pivots. When dealing with a large, complex product, pivoting becomes riskier, and the potential losses in investments become higher. This is particularly crucial for early startups, where the direction to achieving product-market fit is still unclear. A lean mindset is indispensable in this scenario. It involves investing only in essential, validated product features. Following Eric Ries' advice (the author of The Lean Startup): List down the features deemed necessary for your MVP, then cut the list in half, and once more in half.

Agile Mindset: Consider embedding agility across every aspect of the product organisation. For instance, opt for adaptable product roadmaps. Assemble teams with diverse skills to enhance flexibility. On a technical front, incorporating modularity and maintaining code quality is an example of facilitating adaptability. Or establishing lean processes without excessive documentation. When making decisions, consider scenarios that may require change.

Continuous Learning and Innovation: Companies should continuously learn, stay sharp with market and competitive intelligence, and keep an eye on new technological innovations. Regularly assess whether your product aligns with market needs. Evaluate if new technologies could be accelerators or may pose a risk to your product. Encourage your team to adopt a learning-oriented approach by occasionally tackling challenging tasks to stay sharp. Prolonged comfort in the status quo can foster hesitancy towards change.

Key Principles for Successful Pivoting

One great definition of pivoting, as articulated by Ben Yoskovitz, is:

"A pivot is a shift in one aspect of the product focus, based on validated learning."

There are two great principles we can draw from Ben’s definition:

1. Pivoting is a shift in one aspect of the product focus: It entails changing a specific element of the product focus—whether it's the product itself, the target market, or the business model. Simultaneously altering all aspects is not a pivot but a complete restart, erasing valuable accumulated learning.

2. Pivoting is based on validated learning: Pivoting must be supported by validated learning. Deciding to pivot without data poses a considerable risk. Relying solely on intuition or following your competitors is insufficient. Consider pivoting only when data confirms that the current direction needs a change. Even the idea of pivoting is also an assumption. Clearly define this assumption, identify the riskiest hypotheses, and validate them before implementing any substantial change. If the data confirms your intuition, get the team on board and prepare for a change.

The Inspiring Story of Lego

Lego provides an inspiring example of a successful adaptation that has been necessary for its survival for almost a century.

The history of Lego started in 1932 as a Danish carpentry shop producing wooden toys. Surviving multiple challenging periods, Lego made a significant shift, transitioning to plastic material in 1947 and introducing innovative interlocking bricks in 1949. Despite facing challenges, Lego expanded globally and strategically shifted to survive difficult moments.

After almost a century, the company has remained the iconic brand for kids of all ages. What has stayed the same is their mission and vision - to inspire play and creativity, and to develop the builders of tomorrow.

However, they have never stopped innovating and making the changes necessary to stay relevant as the most beloved company for all kids. They align continuously with market trends, such as introducing sets featuring the latest kids' characters. They follow tech trends by introducing digital products or initiating Lego programming for young kids.

Lego's story shows resilience, adaptability, and commitment to their mission.

Final thoughts

Pivoting is a fundamental element in a company's growth journey, influencing businesses at every stage. Rather than something to avoid, it’s better to embrace it and prepare for when it becomes necessary. Establish a culture of experimentation, transparency, adopt a lean and agile mindset, and encourage continuous learning. When this is done effectively, the likelihood of needing a significant pivot is reduced; even if required, you'll be better prepared to manage it seamlessly.

In every organization I’ve encountered, leaders consistently seek ways to increase their team’s capacity and bring new members on board.

When confronted with the pressure of missed deadlines and operational challenges, our initial inclination often leans toward team expansion with the hope of expediting processes. However, more often than not, adding more people means increased waste, and the larger the organization, the more evident the problem becomes.

Picture it like building a Jenga tower. You might feel tempted to add five more blocks to increase its height, but should you? Well, you can, but only if the tower is stable and capable of supporting those additional blocks. Attempting this at the wrong moment could result in a catastrophic collapse.

So, the question arises: do you genuinely require five more people on your team?

The concise answer: perhaps. While the need may arise, it’s advisable only when you’ve established a well-optimized system and ensured it’s prepared for scalable growth.

The common misconception: more people, more productivity

There’s an intriguing phenomenon in teamwork known as the Ringelmann effect. It suggests that when you add more people to a team, each individual team member’s productivity tends to decrease.

This idea was initially observed during a simple activity — rope pulling. It makes sense when you think about it. When you’re competing in rope-pulling by yourself, you’ll likely exert your maximum effort. However, if you’re one of ten people on the same team, your personal effort might not be as intense.

This simple principle applies to various aspects of teamwork, including product development, as research has consistently shown.

There are a few primary reasons behind this phenomenon:

Blurry sense of purpose. As a team expands in size, the array of responsibilities they must manage also grows significantly. As a result, it becomes increasingly challenging for everyone to maintain a clear understanding of the team’s ultimate purpose. When team members lose sight of the big picture, their motivation can diminish.

Increased interdependence. You might add only one new person to the team. However, if you have a team of ten people, adding even one person introduces 10 new connections and interactions within the team. Without a proper system in place, this addition can lead to more frequent communication, higher overhead, and additional interruptions, all of which can hinder overall productivity.

Reduced individual accountability. In a team of 10, it’s common for each individual to bear responsibility for only a portion of the workload. This can sometimes lead some team members to presume that others will compensate if they don’t perform at their peak. While this perception may not be universal, it tends to be prevalent among team members. This is called social loafing — the tendency of individuals to put less effort when they are part of a group.

How to scale your engineering team effectively

As a company expands and the responsibilities within the team increase, it becomes evident that greater capacity within the team is a reasonable necessity.

While it’s challenging to completely eliminate the effects of the Ringleman effect, there are numerous effective practices that can significantly reduce its impact.

To achieve this, you need to establish a solid system. Think of your team as a system comprising people, software, and processes. The flow of your product development process involves external inputs, typically in the form of requirements, and the delivery of outputs, for example new released features.

Growing the system means more people in the team, increased number of input, increased software size, more data, more complex processes etc. To ensure you can handle increased complexity, an optimized system is crucial.

Build a scalable team structure

Smaller teams often outperform larger ones, and there are good reasons for that. If your product development team already consists of 10 people, introducing new members may not be the best move until you’ve revamped your team structure.

However, proceed with any redesign thoughtfully.

When executed effectively, team redesign can be a game-changer. But if mishandled, it can introduce unnecessary complexity and slow down progress.

The process of redesigning teams is unique to each organization, but here are some fundamental principles to guide you:

1. Identify subdomains — Start by categorizing all the tasks your team handles. Is there a clear overarching goal, or does it seem like a mere list of tasks? Look for smaller, manageable areas within your team that can operate independently and align with your company’s overarching objectives.

2. Assess team skills — Take stock of your team members. Are there individuals naturally suited to specific subdomains you’ve identified? Do some team members possess distinct skills and career aspirations compared to others?

3. Review current processes — Dive deep into your team’s current operational procedures. What steps are followed? Where do you rely on assistance from other parts of the team? If your plan involves having a team work independently, you need to do this carefully and avoid introducing complex dependencies between the different subdomains.

4. Conway’s Law and system design — Consider Conway’s Law, a concept in product development suggesting that your team’s design often reflects your system’s architecture. Ideally, each team should operate autonomously, responsible for their own tasks and code management. Making a split in the team and ending up with teams that maintain a shared codebase would not be the most optimal solution.

5. Think about the future — Where do you envision your company in a year’s time? Could your software components evolve into distinct products or even separate businesses? Do you anticipate ongoing team growth, or is the growth just a temporary phase? Each time you reconfigure your team, it’s akin to making an investment, so ensure it aligns with your future objectives.

6. Avoid pursuing perfection — Don’t get caught up in the pursuit of perfection because, honestly, it’s seldom attainable. Think of these principles as your compass, not rigid rules. Achieving the ideal team structure is akin to crafting art—you aim for a balance between your current state and your desired destination. Trust your instincts to discern when it’s the right time to implement changes.

Build scalable software

The accumulation of technical debt can significantly hinder team productivity, although it often goes unnoticed.

Subpar software quality can drastically slow down your team, potentially making them two to three times less efficient. Resolving any defect becomes a headache, and implementing new functionalities can be a very time-consuming process.

Moreover, if your software isn’t designed to scale and you add more team members without a clear improvement plan, it can result in increased costs, inefficiency, and frustration.

Regrettably, addressing these issues isn’t always straightforward. While there may be some quick wins to improve developers’ productivity, enhancing software quality often necessitates a substantial investment. This may involve refactoring critical software components, migrating data, or even rebuilding the software from scratch.

When the quality of your software becomes a significant problem, it’s time to carefully consider your options. Typically, you’ll need to decide whether to invest in improvement or undertake a separate rebuilding project, even if it means temporarily slowing down or halting new development. This ensures a more sustainable and effective long-term solution.

Optimize processes and reduce waste

As your team expands, processes that may have seemed optional for small teams or startups become increasingly essential.

Larger teams naturally entail more communication, which often results in interdependencies among team members. To navigate this effectively, it’s prudent to consider implementing well-defined and somewhat formal processes.

This entails creating comprehensive documentation, outlining detailed procedures, and assigning clear responsibilities. Neglecting to establish clear processes within a sizable system can lead to disorder, and discontent among team members.

While building a software product typically centers on software development, it’s worth noting that developers often spend less than half of their time on actual coding. There are numerous supporting processes involved, such as building, testing, quality check, deployment, and monitoring. The good news is that many of these processes can be automated, presenting significant advantages in terms of both productivity and happiness for developers.

Take the time to review the entire workflow, from conceptualizing a feature to its production release. Examine the entire process, pinpoint dependencies, and identify areas that can benefit from automation and others that require comprehensive documentation.

Having an optimized process can greatly benefit your product development team. It’s entirely possible that through refining your processes, you may discover that you don’t necessarily need to bring on additional team members to manage the current workload effectively.

Final thoughts

Determining the right moment to expand your team is a decision unique to your specific situation. It requires a thorough evaluation and judgment because many factors come into play, and it’s rarely a clear-cut choice.

Here are the essential questions to address before arriving at a decision:

1. Team size — Are your teams relatively small in size?

2. Clear purpose — Does each team have a well-defined purpose that aligns with your overall strategic goals?

3. Bottlenecks — Have you identified and clarified the key bottlenecks within your product development process?

4. Software architecture — Does your software architecture align harmoniously with your team’s structure?

5. Processes and automation — Are there well-established processes in place, backed by extensive automation?

6. Technical debt — Is your software’s technical debt at a manageable level?

7. Strategy — Where do you want to be in one year from now?

When considering team expansion, it’s vital to thoroughly analyze these factors. You should carefully assess the situation, weigh the advantages and disadvantages, consider your broader strategy, explore various options, and ultimately choose the solution that best fits your current circumstances.

Crafting your system is a bit like an art form rather than a straightforward task. It requires careful planning, ongoing iteration and refinement and a clear vision. While your one-year-ahead predictions are probably not fully accurate, taking the initial step towards improvement is crucial to begin the journey. Along the way, you’ll unearth valuable insights, refine your thought process, and enhance your system step by step.

Expanding your team hinges on having a scalable system, which requires a growth mindset and ongoing enhancement.

Originally published at https://blog.logrocket.com on October 23, 2023.

In the realm of business, some debates never seem to lose steam: the question about service-based versus product-based companies, their scaling potential, or strategies to move from one model to another.

Some businesses clearly lean to one of these models, or adopt a well-defined hybrid approach. For others, however, the line between both models is blurred. This ambiguity brings a lot of confusion and misalignment when it comes to making strategic decisions.

In this article, I’ll share my perspective on the difference between both paradigms, the advantages and disadvantages, and why lingering in that "grey area" might be the riskiest move for any company.

Product-centric business model

The core value of a product-centric company lies in its product or product portfolio. This can be software, hardware products, or physical goods. In this context, I am specifically referring to software products.

In a product-centric company, the product is the brand. Customers don't just use the product; they equate the company with it. Take the product away, and—the value the company offers vanishes completely.

In this model, the same software instance is made accessible to all customers. Each new feature developed and deployed enhances the experience for the entire user base.

Engaging with a new customer requires minimal operational costs, primarily revolving around sales efforts. For companies that take the extra step and commit to product-led growth (more commonly seen in B2C companies), even the sales cycle becomes streamlined through the product, further reducing the costs associated with customer acquisition.

Advantages

This business model offers a significant advantage—scalability. Each new customer that a company brings on board contributes to a high margin of sometimes even close to 100%. That is the real advantage of a software company in the product-led growth universe.

Due to this substantial growth potential, a product-centric company often has a valuation of at least six times the ARR (Annual Recurring Revenue).

Disadvantages

On the flip side, a product-centric company typically requires substantial upfront investments. It often begins with a negative profitability until it reaches a critical turning point. If the company successfully reaches this milestone, its growth potential becomes significant.

Another drawback is that the product can become a commodity and lose uniqueness. When that happens, standing out in the crowd gets tough, and customizing to individual needs? Even tougher. That magical sweet spot, the product-market fit, might start to feel like a mirage.

In a product-centric company, the stakes are inherently higher, but so are the potential rewards.

Key focus areas

The success of a product company hinges on two key factors:

Ability to Master the Product-Market Fit: This involves aligning a product seamlessly with the specific needs and desires of the market. Once this alignment is achieved, it naturally leads to growth and an increasing adoption rate for the product. The ultimate goal of the company is to build a product that becomes "sticky" for the customer. This kind of customer magnetism not only fuels growth but also ensures that customers stay happily in your corner.

Ability to Scale: Once a product-market fit is achieved, the main challenge faced by a company is its ability to scale the product, processes, and teams effectively. This involves perfecting the art of onboarding new customers without straining the budget, structuring teams that can keep pace with growth, and refining a product development flow that consistently rolls out new features without creating chaos in the system.

Once this state of operational fluidity is achieved, the company significantly enhances its chances for scaling and advancing to the next phase.

Service-centric business model

A service-centric company operates on an entirely different premise. It serves clients on an individual basis, where each new client signifies a new project and an explicit allocation of additional hours. The math is simple: more clients equals a greater need for an expanded workforce.

Customers associate the company with the people and the quality of their work. They trust the company because they see the value in the people who serve them. In this landscape, employees aren't just assets; they're the bedrock upon which the company's value is built. Without them, you risk destroying the very foundation of the enterprise.

Take consulting firms, for instance. Their key value lies in intellectual expertise. Another example are companies offering software development services. Even if they work with the most cutting-edge technology, they still operate as a service-centric model. The software they produce usually becomes intellectual property of the client, further strengthening the service nature of their business.

Advantages: Service businesses typically require less upfront investment. Engaging with the first client could translate into immediate profitability, making this model highly accessible for bootstrapped entrepreneurs or those with limited capital.

Another advantage is flexibility. A service company could be able to pivot swiftly to meet market demands without the need for time-consuming product adjustments or rebuilding product from scratch. it's all about recalibrating skills and strategies.

Disadvantages: Scaling is obviously a negative aspect for a services company. Every new customer becomes a new project for which dedicated capacity should be allocated. The ability to reuse the work that has been done for previous projects is limited because every customer has unique specific needs, and the intellectual property of the software built before is typically owned by the customers.

With constraints on scalability and growth, service-centric companies often find their valuations hovering below a 1x multiple of their ARR.

Key focus areas

The success of a service-based company depends primarily on two crucial factors:

Human Capital and Work Quality: The key element of a service-based organization are its people, who are the front-line representatives interacting with clients. These individuals are those who build trust with customers. It is crucial to recruit top-tier talent and to continually invest in their professional growth. Team members should embody qualities like: a customer-oriented approach, an affinity for inventive problem-solving, and the flexibility to address each client's unique challenges.

Tailoring Solutions to Individual Customer Needs: Customers seek assistance from service-based companies to resolve their specific issues. While optimizing internal processes and methodologies to achieve efficiency is essential, the foremost objective of a service-centric company should be to meet the distinct challenges of each client. This personalized approach aligns with customer expectations and is critical to the company's success.

Hybrid approach

Some companies make a strategic decision to blend the strengths of both worlds, creating a hybrid approach.

For instance, a product-focused company that builds software products can enhance its offerings by introducing a layer of services. The aim is to integrate these services in a way that enhances the value of their various products, fostering a deeper and more trusted relationship with clients, ultimately, leading to higher customer retention.

A company primarily centered on providing services can also incorporate elements from a product-oriented approach. For instance, they could target specific customer problems, develop methodologies tailored to those problems, and may even utilize in-house technology to streamline the projects execution. Importantly, this addition doesn't transform the company’s core identity; rather, it enhances operational efficiency and project delivery.

This approach naturally affects the company's valuation, with the services layer maintaining a relatively lower value than the product layer.

Ambiguity is a Huge Risk

Operating within an ambiguous framework that blurs the lines between a product and service orientation is fraught with risk. Unlike a well-defined hybrid model, where the roles of each operational layer are clear, in this scenario, elements from both worlds are inconsistently merged, leading to detrimental outcomes.

The biggest problem is that persisting in this state of ambiguity leads to misalignment among various stakeholders in the strategic vision and causing tension in day-to-day decision-making. For example:

• Customers who perceive the company as a service provider will demand unique features to address their specific needs.

• Investors leaning towards a product-centric company will expect aggressive growth metrics, pressuring the company to focus on scaling rather than customized solutions.

• Executives with a services-centric mindset will incentivize sales representatives to prioritize securing large deals, often neglecting the impact on the product.

• A customer-facing team trained to think in a services-centric way will aim to address specific customer needs, even if they are unique and customer-specific.

• Product managers trained to think product-centric will resist implementing customer-specific features.

• Product development teams used to work in a services-centric company may forget the scalability of the product as a critical factor, resulting in a product that is, to a large extent, customer-specific. They may also completely ignore the importance of product adoption as a factor for product success.

This lack of clarity can lead to a state of internal and external confusion, with stakeholders pulling in different directions, ultimately steering the organization in a direction of decline instead of growth.

Strategic Clarity: The Imperative of Choosing the Right Operational Model

The choice between operational models—be it product-centric, service-centric, or a well-defined hybrid—should be a deliberate decision shaped by the company's circumstances, market dynamics, and company’s core values. Each model comes with its own set of pros and cons, and as long as it is a deliberate decision, choosing one or the other model can work well.

But it's the clarity of choice that is paramount. It is crucial that companies should strive to avoid remaining in the ambiguous space between these paradigms. Remember, ambiguity can lead to confusion among stakeholders, be it investors expecting quick scale or customers demanding personalized solutions. Such ambiguity hinders growth by creating a discordant pull between different organizational objectives and stakeholder expectations.

To thrive in today's competitive market, companies must operate with strategic clarity, decisively choosing an operational model that best suits their unique circumstances.

Many thanks,

Marina

If you are a product leader, crafting a product strategy is only the first step. What often proves more challenging is executing the strategy.

How can you ensure that the envisioned product strategy and the key company priorities become the guiding forces for your teams?

How can you instill your vision into everyone's mindset, guiding daily team activities toward this strategic path?

Are Your Teams' Priorities Aligned with Your Product Strategy?

Imagine an orchestra where musicians play their instruments without coordination, each pursuing their own tune. The outcome is a cacophony of discordant sounds.

In a business context, when individual teams execute based on their divergent priorities, disconnected from the company's overarching goals, the consequences are clear: disorganisation, inefficiency, and stagnation.

In cases of alignment, on the other hand, teams take proactive ownership of executing the right priorities. Daily task prioritisation seamlessly aligns with the company's broader goals and timelines.

This alignment naturally fosters a culture of productivity. Time and effort are invested in activities that maximise the value of the overall strategy. The result is a harmonious symphony that resounds with the audience.

In the realm of business, achieving perfect harmony is nearly impossible. However, as a product leader, you can do a lot to mitigate misalignment and its detrimental consequences.

One basic and effective way to solve this is to structure your product teams in accordance with your product strategy.

The Impact of Team Structure on Product Strategy Execution

Let's explore some scenarios where aligning product strategy with team priorities becomes a formidable challenge.

Vertical teams

In the traditional setup, teams followed a vertical structure, often working in isolation. Departments like sales, marketing, and software development operated in silos, and this division extended even further within technology teams: frontend, backend, and data teams. Each team specialised in specific areas and collaboration across teams was limited.

This approach does have its benefits, fostering specialisation and team cohesion. However, when it comes to aligning the priorities of such specialised teams with the broader company objectives, there is a huge challenge.

Can a backend team truly envision, let alone be held accountable for, achieving a business outcome?

Even if they aspire to contribute, they often find themselves heavily dependent on other teams.

In this configuration, success remains attainable, but it relies on the crucial factor of cross-team collaboration and the presence of a dedicated leader capable of overseeing and synchronising various objectives across multiple teams. Yet, managing this level of coordination can be very challenging.

Large teams

In agile methodologies, there's a well-founded principle advocating for smaller team sizes. Why? Because it nurtures team cohesion, transparency, and productivity.

While I won't advocate for a concrete number of team members, I believe that every team should have a clear and specific responsibility within the broader business context.

A large multidisciplinary team often indicates that too many diverse activities are being handled by the team members. They become overwhelmed with their workloads, making it challenging for them to understand the significance of strategic objectives. Their work becomes a mere checklist of tasks, lacking a clear vision of the ultimate goal and purpose.

How to Organise Your Teams to Follow Your Product Strategy

The design of the product organisation should naturally align with the product strategy.

For instance, if you're transitioning from a project-oriented setup to a product-oriented one, it's counterproductive to keep teams dedicated to specific projects.

If sustainability becomes the new key pillar of your product strategy, it might make sense to establish dedicated teams to focus on this topic.

Identify the primary objectives

Begin by assessing your organisation's core goals. What are the key building blocks of your company, and what initiatives are in place to foster meaningful change and progress?

When the responsibilities for a single initiative are distributed among different teams, each with its own set of priorities, making significant progress on that initiative becomes considerably challenging.

For any initiative to succeed, it requires a dedicated team with a genuine passion for the topic and the capacity to commit time effectively. This designated team should take full ownership of the initiative. They should own the problem and be ready to delve deeply into finding solutions.

Align on the vision

You can have well-defined initiatives and a great vision to achieve outstanding outcomes, but it's the people who execute the vision, especially when it comes to the product strategy. Success relies on their trust and understanding of the vision. Communicating and aligning on the vision is crucial.

For every team you create, they need to understand the 'Why.' What is their purpose, and why are they doing it?

This is especially crucial for the person who will lead the initiative and potentially become the team leader. Take the time to align on the vision until they experience that 'Aha' moment, making their purpose crystal clear. They should internalise the vision and develop their own unique narrative.

Consider virtual teams

A team dedicated to a specific initiative often comprises individuals with diverse skills. In some cases, it may be worthwhile to consider such a team as a permanent fixture in your organisation's structure. This is particularly true when you anticipate that this building block will remain a key and potentially growing part of your business in the long run.

In other cases, such a significant shift may seem too disruptive, and a more flexible approach may be preferable. In such instances, creating a 'virtual team' composed of cross-functional members from different departments can be the way forward. These virtual teams operate without a formal hierarchy and are typically temporary, aligning with specific objectives. This approach is agile, adaptable, and tailored to meet the current goal.

Make a gradual transition

When making a transition, my preference is to take a gradual approach.

Big changes can often be met with resistance, so it's crucial to allow people time to adapt and build trust in the process. People need to adjust to the new setting, gain additional knowledge, and, most importantly, feel passionate and motivated about their new role.

Gradual transition means that people are carried along on this journey. It allows for adjustments and refinement without causing significant disruptions in the organisation.

Final thoughts

Aligning your teams with your company's product strategy is a journey with challenges and opportunities. It's not a one-off event; rather, it's an ongoing process.

As you persistently fine-tune your team structures and align them with the product strategy, you'll discover that the harmonious symphony of coordinated teams and company objectives can lead to resounding success.

One last thing!

I hope you found this article enlightening. In upcoming editions of my newsletter, I'll delve deeper into the practical aspects of designing teams, equipping you with hands-on insights. 

To ensure you don't miss out on any of these valuable insights and to show your support for my work, please consider subscribing. Your support is invaluable!

Subscribe now

Share this article with others. By doing this, I’ll collect more questions from readers and ensure more relevant articles.

Share

Comment in the post or reach out to me directly with any feedback or questions that you’d like to be addressed in my next articles.

Leave a comment

Many thanks,

Marina

Strategic priorities often don't receive the deserved attention

A strong product strategy is an essential factor for the success of any product. It acts as the crucial link between the product vision and the product roadmap. It outlines the overarching plan for how you meet the unique needs of your customers in a way that is better than your competitors.

When deployed effectively, product strategy can serve as a prioritization engine. It gives focus, it aligns everyone on the same goal, and helps to prioritize tasks towards achieving that goal. Unfortunately, in practice, product strategy often becomes a forgotten document, pushed aside by urgent issues or requests from various stakeholders. Customer requests, sales requests, and technical problems that require immediate attention often take precedence over the strategic items. When this happens, over time the product becomes a collection of features with no competitive advantage, and weakens its position in the market.

In my previous article, I gave some tips on how product managers can free up time from tactical activities in order to allocate more time on strategic work.

But even if you as a product manager or leader have developed a great product strategy and have clear strategic initiatives, how do you ensure that the strategic high value items do receive the deserved attention during the execution? In this article we explore how to prioritize high value items in product development.

Recognize what are strategic high value items

Strategic high-value items can make a big difference for your product. They go beyond building features that benefit only one customer. Instead they aim to improve the overall experience for many or all your customers. They might enable you grow and increase profitability of your business. When implemented well, a high-value item can set your product apart and even be a real differentiator.

For example, creating a mobile app version of the product could be classified as a high-value item, providing users with increased accessibility and convenience. This feature would significantly improve user experience for existing customers, but could also attract new customers who may not be able to use the web version of the product frequently. Implementing this feature would not only have a positive impact to customers, but also to your business, as this will likely lead to increased sales.

On the other hand, if a customer requests a specific feature that is unlikely to be used by other customers, it is not a strategic high-value item. If a simple design and great user experience is one of your product differentiators, but you are requested to build a feature that makes the product more complex, this request is not aligned with your strategy and is not a strategic item. Small feature improvements or bug fixes are not strategic high-value items as they only lead to small incremental improvements, without a significant visible impact.

How to Prioritize Strategic Initiatives

Prioritization can present a constant challenge, especially for product managers, as it involves balancing the varying viewpoints and interests of stakeholders. Customers may be eager for new features, the business may prioritize new initiatives, while the engineering team may require time to enhance technology and improve development productivity.

And prioritising strategic items just once is only a short-term win. What is more important is to establish a system in place, aligned with everyone in the company, that can help in prioritization. Such a system should be transparent, should capture the interests of various stakeholders and importantly should explain the rationale behind a specific prioritization decision.

Bring strategy-awareness

To be able to prioritize strategic items effectively, the first step is to make sure that everyone in your company is well-informed about the product strategy and understands the significance of strategic execution. When employees have a clear understanding of the company's product vision and strategy, they are better equipped to comprehend why certain decisions are made. This understanding helps align everyone's efforts towards improving the current situation and elevating the strategic importance of their work.

Understand how time is currently spent

Next, spend some time with your product development team to understand how their time is currently spent. Categorize the items they're spending their time on. For example, you might define categories like bug fixes, feature enhancements, customer requests, and technical improvements. Next, define how the effort is currently distributed. For example, they might currently spend 20% on bug fixes, 30% on customer requests, 15% on technical improvements, 30% on feature enhancement and only less than 5% on high-value items. This picture will be different for every team. Add the buckets that you think are important and that you should be working on for improvement.

Gradually increase the time allocated on strategic execution

Once you have a clear understanding of how time is being spent, think about what you can improve. Your goal should be to increase the time associated to strategic items. However, it's important to recognize that you can't expect to do this overnight. You can't simply allocate 60% of your time to strategic implementation for the upcoming sprint, while ignoring urgent security issues already in production. To get to the state where you can spend 60% of the time to strategic execution, you need to work on some improvements. It's a gradual process that gets better over time.

For example, if you realize that currently 20% of your time is spent on bug fixing, it's a sign that you need to improve your testing process and test automation to release your product with fewer defects. If you're spending a lot of time on customer requests, evaluate which of these requests align with your own strategic plan and which don't. Discuss with the product board, and try to be strategic about how you manage requests. Decide on the border line between accepting or rejecting customer requests.

Over time, as you streamline and improve your processes, you'll have more time to allocate to strategic items.

Three critical principles for effective strategy execution

Strategic initiatives are where innovation happens. It is adding adding something new to the product that significantly increases its value for customers. However, achieving success in this area requires having effective processes in place. While we won't delve into the details of strategy execution in this article, we'll highlight three principles that are critical for success.

Every strategic item needs to be aligned with the product and company strategy. It's obvious but still important to emphasize, any strategic objective you set should be aligned with the product strategy and the broader company strategy. This requires good understanding on the users, the market and the differentiators. When the strategy is clear, you can work on defining objectives aligned to that strategy.

Define outcome-driven objectives. When setting strategic objectives, it's important to express them in terms of outcomes rather than features. The outcome is the benefit we aim to achieve for the customer, while features are the means to deliver these benefits. To track outcomes effectively, Objective Key Results (OKRs) can be a useful tool to help maintain focus on what truly matters.

Adopt experimentation approach. During the implementation phase, it is critical to have an experimentation approach. There are usually many assumptions, and it's important to start small and validate these assumptions continuously. This helps avoid spending valuable time on ideas that are not proven. By using validation, you can move forward confidently with the most promising concepts, while avoiding costly implementation mistakes.

Conclusion

Running out of time to implement strategic initiatives can be frustrating and feel like an endless cycle. However, there are pragmatic steps you can take to address the issue. By acknowledging the problem and making others aware of it, you can start taking small but impactful steps towards improvement. Over time, even small improvements can lead to significant progress. As a product leader, these steps can help your product stand out and gain a competitive advantage in the market.

The complex nature of the product management role

The role of a product manager is complex and multifaceted. You have a broad range of responsibilities, from ensuring high customer value, to keeping your product competitive and profitable year after year. The success of the product depends heavily on your work.

Product managers work should be a healthy balance of both Strategic and Tactical work. On one side, product managers need to be strategic thinkers, who decide on the future direction of the product. On the other side, daily tactical activities like prioritisation or enhancing the product features based on customer feedback is also the core of the product management role. To excel as a product manager, it's essential to find the right balance between strategic and tactical activities.

However, product managers are very often pulled into daily tactical activities leaving them no room for strategic work. Endless requests are coming from various stakeholders, issues occur in production, or customers complain about the latest features. The result is not only them being stressed and overwhelmed, but also this has a long-range impact of the product and the company in general.

So, how can you manage a balance between both strategic and tactical activities.

Why is it so easy to become tactical-only product manager

Tactical activities involve addressing day-to-day issues, such as fixing urgent problems that require immediate attention. These problems are given high priority due to their urgent nature, and because solving them has an immediate impact. In contrast, strategic problems relate to long-term success and often fall under the "important but not urgent" category. They may never be prioritised without proper management.

Despite this, many requests often land on the product manager's table because product managers play a central role in the product. They have deep knowledge of various perspectives of the product, technical, customer or business related. When no clear processes and responsibilities are set, a new issue without a clear owner will be directly passed on to the product manager.

Additionally, product managers may be more tactical due to their professional background, such as an engineering or sales background. When faced with an engineering issue, for instance, an engineering-oriented product manager may be easily distracted and offer hands-on support to the engineering team.

The danger of ignoring the strategic element

Focusing solely on tactical activities can bring short-term gains. For instance, when your highest paying customer has requested a new feature, it is logical to give this request a high priority - otherwise there is the risk of losing the customer. However, repeating this approach over and over can have lasting negative impacts on the product in the long run:

• The product loses its competitive advantage, and its brand promise becomes blurry.

• The product becomes a collection of features that offers bad user experience.

• The quality of the product may suffer as implementing ad-hoc requests often leads to cutting corners and deviating from the initial design.

• Scaling the value of the product becomes difficult as the features implemented are tailored to a specific client rather than high-value strategic features.

Over time, the product loses its essence and weakens its market position.

Free up time for strategic work

Strategic work requires continuous effort and dedicated time. It is therefore necessary to first free up time by doing less tactical work.

Reducing the tactical work may sound challenging, especially when faced with an overwhelming number of important daily activities. However, it's important to take a step back and acknowledge the problem. Once you're aware of the issue, you can gradually work on improving the situation.

Begin by critically analysing all the tasks you've completed in the past period. Ask yourself:

• Was the specific task necessary and what would have been the impact of skipping it

• Could that task be streamlined or automated to save time for yourself and others

• Was that task your responsibility as a product manager or it could have been done by someone else.

While certain tactical work, such as working with the product team to refine the product based on customer feedback, is important and should be a central part of your role, there may be other tasks on your list that can be delegated.

You may find that some tasks are assigned to you simply because you have the skills to complete them. For example, if a customer calls to report a product issue, and the support team asks for your help because you know the product well, this is not your responsibility. While it's good to help out when possible, it's more important to ensure that the support team receives adequate training to handle these tasks in the future.

Over time, by streamlining your workload and delegating tasks to others, you'll notice that the processes become more efficient, and every task is effectively getting its home without you needing to be in the middle. This will free up more of your time and mental energy, allowing you to focus on strategic work and make a more significant impact on your organisation.

The key strategic elements of the product management role

Let's delve into the crucial strategic elements of the product management role. While each organisation may have its unique aspects, the following are the main strategic areas on which you, as a product manager, should focus:

1. Defining product vision and strategy: As a product manager, you're responsible for creating and communicating the product vision and strategy to the rest of the organisation. This involves understanding the market, customer needs, identifying and maintaining the competitive advantage of your product. It's important to keep in mind that developing a strategy is an ongoing process that requires continuous iteration and refinement.

2. Conducting market research and analysis: Similarly, staying up-to-date on industry trends, conducting market research, monitoring competitors, and analysing customer feedback are essential.

3. Monitoring product performance: Using data to enhance the product is incredibly valuable, yet often under-utilised by product teams. If your team isn't experienced in this area, working with them to integrate product analytics processes would be beneficial. This will help you monitor the product's performance and make data-informed decisions.

4. Developing a prioritisation engine: Prioritisation is a core responsibility of a product manager. It's not just about choosing feature A over feature B for the next sprint; it's also about developing a prioritisation engine that aligns with the strategy and helps you and your team prioritise effectively. An effective prioritisation system will free up time and mental energy and, importantly, connect strategy with execution. Stay tuned for the next blog post, where we'll dive deeper into this topic.

Conclusion

Product management is a demanding role that requires a considerable investment of time, effort, and mental fortitude. It can at times feel overwhelming and stressful. But it does not need to be that way. When executed effectively, a product role can be an incredible experience.

A successful launch that changes the life of a customer, combined with enhancing the company's reputation, profitability, and growth potential as well as the the instilled proudness of the product team, can be an incredible fulfilling journey.

Interested in seeing more posts from us? ,Register to join the community.

Share this article