You can’t schedule a breakthrough.

Roadmaps are designed to align teams and drive execution. Traditionally, they answered one question: What will be delivered by when?

Today, many organizations use outcome-driven roadmaps — focused on impact rather than features. A meaningful step forward. But even outcome-driven roadmaps are still instruments of execution. They optimize toward defined objectives and assumed directions.

Innovation begins earlier. Before the outcome is defined and the metrics are known.

It begins with uncertainty and exploration. With the question: What if…?

This is where organizations get stuck. They want innovation — but their operating model is built primarily for execution. And execution is hungry. It consumes time, talent, and unprotected ideas. The system is optimized for today — not tomorrow.

Common Reasons Why Innovation Fails

Organizations optimized for execution unintentionally suppress exploration. Their systems reward predictability, efficiency, and delivery — not discovery.

Three patterns come up repeatedly:

Execution consumes all capacity. Roadmaps, targets, and operational pressure expand to fill every available hour. Exploration becomes something to do later, when things calm down. In reality, later never comes.

Innovation becomes an event. Hackathons and idea days create real energy. People get excited, ideas flow, and for a moment it feels like anything is possible. Then Monday arrives. Without a continuation plan, ideas fade and everyone returns to their real work. Until the next hackathon.

Innovation gets detached from reality. Innovation labs and dedicated task forces are a genuine step forward. But the real risk is drifting too far from real users and real constraints. They produce interesting concepts that struggle to land back in the core product. The ideas can be good. The distance is what makes them impractical.

In all three cases, innovation isn’t rejected. It just doesn’t have enough space — or structure — to survive.

The Innovation Track

An Innovation Track is a deliberately protected space alongside your delivery roadmap — designed for exploration, not execution.

It exists to investigate opportunities that don’t yet fit into quarterly targets, but could materially shape the future of the business. It may explore emerging technologies, new customer segments, new value propositions, or shifts in the business model itself.

Its purpose is simple: test what might matter next — before committing the organization to build it.

It is time-bound, hypothesis-driven, and importantly, focused on real problems. It’s a structured way to reduce uncertainty before an idea enters the roadmap.

What Makes It Work

A small, focused, startup-like container inside your company — built to explore one meaningful opportunity with intention. An effective Innovation Track has three key components: a clear charter, the right people, and a deliberate time window.

The Charter

A charter is a simple one-pager that sets direction without prescribing output. It should capture:

The Team

Innovation doesn’t require a large team. In fact, small team learns much faster. The ideal setup looks like a startup founding team: 1–3 people, cross-functional by default, empowered to decide without permission, and connected to real users.

Small, sharp, and autonomous. That’s the formula.

The Time Window

Innovation Tracks are intentionally short. Four to eight weeks is the typical window — long enough to learn something real, short enough to avoid drifting. The expected outcome isn’t a polished feature. It’s a decision: do we continue, pivot, or stop?

Protecting the Track Without Isolating It

An Innovation Track only works if the team can explore freely — without being pulled in day-to-day execution. But there’s an equally dangerous failure mode: complete isolation so that the work loses touch with reality.

The art is in building a protective bubble with a door.

Protected from delivery pressure. No sprint commitments. No last-minute requests. The team needs to be temporarily removed from the urgent dealines so they can think clearly and be creative.

Stay connected to the real world. Exploration without grounding becomes fantasy. The team must have access to engineering realities, domain expertise, business stakeholders or real users. This is what keeps the Track connected to the real world.

Join only the rituals that matter. Monthly demos to share learning. A regular check-in with the sponsor. Visible to the organization — but not interrupted by it.

Make expectations explicit. Everyone around the Track should know what the team is working on, how long it runs, and why they aren’t available for delivery work. Clarity protects the team better than isolation.

Governance: Keeping It Light

At the end of every cycle, gather the team, the sponsor, and a few key stakeholders. The question on the table is straightforward: what did we learn, and what does that learning mean?

The conversation centres on three things: the story of the work, the strength of the signal, and the path forward. The decision itself is:

• Continue — the signal is promising enough to dig deeper.

• Pivot — the opportunity still feels real, but the hypothesis needs to shift.

• Pause — the idea is sound, but timing or dependencies aren’t right.

• Stop — the exploration served its purpose. But the idea isn’t worth pursuing further.

From Exploration to the Roadmap

Graduation is the moment an idea stops being a possibility and starts becoming a plan. An Innovation Track should never drift into delivery by accident — graduation is a conscious, evidence-based step.

A Track is ready to graduate when three things are true:

• there is a real signal (not a perfect metric, but enough evidence to believe the opportunity is meaningful),

• the idea is buildable (the team understands feasibility well enough to move into structured experimentation), and

• there is a value case (you know who benefits, how, and why it matters).

From there, the work becomes more tangible. It’s not yet time for full delivery, but for more structure than exploration. The team defines the smallest meaningful version, builds early prototypes, validates core assumptions with real users, and identifies early risks.

Once that work shows consistent value, the idea is ready for the roadmap: ownership defined, scope agreed, investment committed. Good graduation is about commitment informed by evidence.

How to Start in 2 Weeks

Getting started doesn’t require a special team, a new budget cycle, or a grand announcement. You can launch your first Innovation Track in two weeks — with the people and knowledge you already have.

Step 1 — Pick the opportunity. One problem or emerging question that keeps resurfacing. The kind of thing people say “we should look into this” about, but never do. Frame it as a question worth exploring, not a solution to build.

Step 2 — Form the team. Identify 1–3 curious, cross-functional people. Not the busiest — the most motivated. Nominate a sponsor who will protect the team and own the graduation decision.

Step 3 — Write the charter. One page. The problem, your hypotheses, the signals you’re looking for, the boundaries, and the timebox. Do it together in a single session. That conversation is the first act of exploration.

Step 4 — Set the conditions. Give the team temporary protection from delivery work. Make expectations explicit to everyone around them — what they’re working on, how long it runs, and why they aren’t available for other requests.

Step 5 — Start exploring. Let the team run. Talk to customers, review data, test early assumptions. The goal isn’t a polished output — it’s to start reducing uncertainty.

The first governance conversation happens at the end of the cycle, 4–8 weeks in. That’s when you decide what comes next.

The Real Question

Innovation thrives in a space that is intentional, protected, and connected — where ideas can be tested without pressure, explored without drifting, and evaluated with evidence.

The organizations that sustain innovation through scale aren’t the ones with the best ideas. They’re the ones that built systems where good ideas can survive long enough to become something.

The roadmap will always be there. Execution will always feel urgent. The question for every product and tech leader is whether they’ve built anything to protect the space before the roadmap — the uncertain, generative space where the next version of the company is beginning to take shape.

Subscribe now

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

At one point he said:

“I want to do the work that’s most important. Not what’s most paid.”

He gave me his two options:

• Cardiologist — helping sick babies and children

• Mountain rescuer — saving people in the mountains

That conversation stayed with me, because there was an important career lesson in this.

Many adults do the reverse.

They start with salary, title, or status first — and only later confront the reality: they’re unhappy, constantly stressed, or burning out under expectations they can’t sustainably meet.

The Adult Mistake

Salary is measurable. Titles are visible. Promotions are socially rewarded.

So adults do what seems rational: aim for the bigger title, the higher package, or join the “hot” company. This is how they define success.

And somewhere down the road they face the reality: a role that doesn’t match their personality, a culture that wears them down, or a mission that doesn’t motivate them.

A bigger title doesn’t fix a bad fit. It just makes the misfit louder.

The Career Equation I Trust

If you want to make career decisions that are both meaningful and sustainable, I trust this simple equation:

Here’s what that means.

Values & Principles (what you can’t compromise on)

Values and principles are your non-negotiables.

This is not about the list of values on a company website. It’s about what the company actually stands for in practice.

Values and principles show up through the mission a company pursues, the behaviours it encourages, and the trade-offs it makes to achieve its goals.

Your happiness at work depends heavily on whether you’re surrounded by behaviours that align with — or violate — what you personally consider acceptable.

To be clear: you don’t need to fully align with everything. If the company loves big parties — and you don’t — that’s fine.

But if the company normalizes behaviours you dislike or oppose (continuous overtime, politics, cutting corners on safety, treating customers poorly), that misalignment will slowly wear you down.

Strategy is part of this, too.

If the company competes on too many fronts while you value focus — or constantly shifts priorities while you prefer a stable operating rhythm — that mismatch will drain you over time.

So watch reality:

• What trade-offs get made to meet deadlines?

• What behaviour gets encouraged — and what gets ignored?

• Who gets promoted, and why?

• What keeps getting prioritized — and what always gets deprioritized?

That’s the values-and-principles system you’ll be living in every single day.

Capability Fit (how you’re wired to work)

This is the part many of us fail to answer honestly — and then wonder why a “great” job feels heavy.

You can build knowledge over time. You can learn a domain. You can stretch into new responsibilities.

But how you’re wired to work — the kind of work that gives you energy and focus — doesn’t change easily. It can change, but it usually requires openness, intention, and time.

A simple way to describe it is three work modes:

• Builder (often: individual contributor): you enjoy doing tasks on your own. You thrive when you go deep and build — solving, designing, shipping, writing, becoming expert at a craft.

• Enabler (often: people manager): you like to guide others and help them do great work — coaching, aligning, setting direction, removing blockers.

• Visionary (often: accountable leader): you thrive when you set a vision, design a system others can execute, make decisions under uncertainty, and carry accountability.

This isn’t a hierarchy. You can be highly successful in any of these.

It’s also not black-and-white. Most roles include some building, some enabling, and some decision-making. What matters is which mode consumes most of your week. If 70–80% of your time sits in a mode that drains you, your happiness will eventually suffer — even if the remaining 20–30% is enjoyable.

But watch out. Titles can be misleading.

A role’s title suggests a mode, but the environment and culture often determines the real one: the company size, operating model, manager expectations, and how ownership is distributed.

Misplacement can be hard.

For example: if you love building, but your role is mostly chasing alignment, reporting, managing others who build — you might be “successful” on paper and still feel depleted every week.

If you have a strong drive to lead, own vision, and make decisions, but your role keeps you in a space with little ownership, you’ll feel constrained.

This matters regardless of where you are in your career. If you’re junior but feel a strong need for ownership and vision, look for environments where you can own something, even a small scope, or managers who value autonomy.

Market Demand (where your fit is rewarded)

The first two factors are internal. But there’s also external reality: market demand.

You can have a strong internal fit — values and capability fit — but if the market doesn’t value that combination right now (in your geography, level, and industry), you’ll feel stuck, underpaid or you’ll struggle to find the next job opportunity.

Market demand doesn’t replace your values or identity. It answers a practical question:

Where can my work be actually valued today?

A few signals to look for:

• Are there many roles that match your profile?

• Are multiple companies willing to pay well for this combination of scope and capability?

• Is demand increasing or slowly declining?

A concrete example: over the last years, Security has repeatedly gone through waves where it moved from “nice to have” to “board-level priority”. In those moments, the same person with the same capability fit suddenly has more options, stronger bargaining power, and faster career progression.

Market demand works like that across many areas (e.g., cloud migrations, data/AI, privacy, sustainability). Follow this trends. Because it’s not just what you can do — it’s when and where the market urgently needs it.

The Intersection (where you should optimize the deal)

Once you’ve found a role that fits your values and capability fit — in a market where that combination is in demand — you’re in the right place to optimize the deal.

This is the part many people get backwards. They start with compensation.

Compensation is a powerful lever, but it’s a terrible compass.

So here’s the order I recommend:

1. Get the fit right first.

2. Then negotiate inside the fit.

Inside the overlap of the three factors, you can negotiate confidently because you’re not trying to “buy” motivation — you’re pricing your contribution.

If you optimize the deal while forgetting the rest, you may win the offer — but pay for it in happiness, health, or time.

Why This Works: Flow Wins Force

This equation isn’t just a career advice. It’s also a performance strategy.

When your values and capability align with the work you do — and the market rewards it — you’re much more likely to spend time in Flow.

A flow is a state in which people are so involved in an activity that nothing else seems to matter. The experience is so enjoyable that people will continue to do it even at great cost, for the sheer sake of doing it.

When you operate in flow, productivity is highest.

It’s also where your next opportunities come from. When you’re operating in flow, your output improves, your confidence grows, you build a stronger track record, and people notice.

Even in a saturated market, this is where you tend to stand out — because you’re not just “doing the job,” you’re getting better at a much higher tempo than the rest.

When you’re misaligned, you can still perform — but it often takes force. And force is expensive and takes time.

Facing Reality (and choosing consciously)

There is an important nuance to be added. Often life doesn’t allow for the perfect overlap.

At the end of the day, you need to pay the bills. Often you need to take a role that’s not ideal.

That’s fine.

What makes it mentally heavy is not the imperfect choice — it’s the confusion about why you made it.

If you’re clear with yourself (“I’m taking this role for stability for the next 12 months,” or “I’m building a skill that will open doors,” or “I’m buying time while I search for a better fit”), you gain peace of mind and you can make a plan instead of silently resenting the job.

Try a Small Exercise

If you want to make this practical, assess your current role (or the one you’re aiming for) using this simple framework.

Write down:

• Your non-negotiables: what you won’t tolerate. Do you see any mismatch? If yes, your best fit is probably elsewhere.

• Your dominant work mode: what energizes you most — being a Builder (deep work and craft), an Enabler (helping others do great work), or a Visionary (vision, decisions, and outcomes). Then ask: what does your role actually require most of the week?

• Market direction: is the domain you’re in growing, stable, or shrinking? Are there roles you’d want in 1–2 years — or is it narrowing?

Then answer one question:

What’s the smallest change I can make in the next 30 days to move closer to the overlap?

That might be choosing a different team, reshaping your scope, changing how you spend your week, or even targeting a different type of company.

Back to The Story of My Son

My son is currently prioritizing value. He wants to do what’s “most important.”

But over time, I hope he learns something even more powerful:

You don’t always have to choose between what matters and what you enjoy. You can combine both.

Maybe he won’t become a mountain rescuer or cardiologists.

Maybe he’ll build robots that rescue people in the mountains. Because he genuinly enjoys building robots. Or maybe he’ll work on medical technology that helps children live longer.

The adult version of that lesson::

Start with Values & Principles. Understand your Capability Fit. Respect market demand.\

Then — inside that intersection — optimize for salary.

That’s how you grow a career that looks good on paper and feels good in your body.

Have you ever felt that the way decisions are made in your company is slowing your work down?
Or that the tech debt you’re paying for today is really the result of yesterday’s decision-making problems?

Maybe the wrong people made the call.
Maybe not all the data and constraints were on the table.
Maybe the people closest to the problem were never asked.

One of the biggest success factors for a company is its organisational model.
And I don’t mean job titles and reporting lines. I mean the decision-making structure: who decides what, based on which input, and how those decisions flow through the organisation.

You can think of this as a system: ideas pop up from teams, leaders, customers. They flow through the organisation, and some of them eventually become decisions that are executed.

But on their way to execution, things can go wrong:

• Bottlenecks – everything has to pass through one or two people.

• Good ideas get blocked because they land in the wrong forum or never reach the right owner.

• Bad ideas get promoted and prioritised without solid data or reasoning.

• Too many ideas are accepted without structure, and the product slowly turns into a mess.

If you don’t design this decision system deliberately, it will design itself. And you probably won’t like the result.

Examples of Immature Decision Design

Let’s dive into a few classical examples that point to a low maturity of the decision making system.

Example 1 – When one person becomes the decision bottleneck

In a young company, having one strong person at the centre of decisions can work surprisingly well.

Often that person is the CEO or CTO. Sometimes it’s a highly trusted senior engineer or other “glue person” who’s been around forever and seems to know everything.

They know the product inside out. They sat with the first customers. They remember every shortcut and trade-off made along the way. At that stage, routing major decisions through them is often the fastest and safest way to move.

The problem is that many organisations keep this decision pattern long after they’ve outgrown it.

The consequences:

• Decisions slow down.
  Teams are ready to move, but the next available slot in this person’s calendar is in a week or two.

• Decisions are made too far from the details.
  When every big choice is compressed into a short call or a couple of slides, a lot of nuance gets lost: edge cases, UX details, operational constraints. The decision might be directionally sensible, but misaligned with the messy reality of how the product behaves today and how the teams actually work.

• Teams stop feeling real ownership.
  Once the pattern is established, people either

  • relax, because “someone else is carrying the load”, or

  • get frustrated that “someone else is making the decision for us”. They might tweak slides to “sell” their story, or quietly give up on what they believe is right and fall back on: “We just follow a given direction.”

This is a decision-making system that was never designed for scale – one that still assumes a single person can and should sit in the middle of everything.

Example 2 – When no one owns a domain end to end

Another common pattern: many people shape a critical domain, but no one owns it end to end.

This domain might be the overall product experience, the overall product architecture, or a key product capability (onboarding, billing, search, integrations, etc.).

Different parts of the organisation drive different changes:

• Commercial teams push for features to close key deals.

• Operations pushes for changes to reduce manual work.

• Engineering pushes for refactors, performance and reliability.

Each initiative is valid. And each group has enough influence to get some of their needs into the roadmap. What’s missing is a clear owner of the domain as a whole – someone whose primary responsibility is to ask:

“How do all these changes fit together into one coherent system or experience?”

When everyone is pulling hard on their part of the rope, with no end-to-end owner for the domain, the overall direction is accidental.

Over time, you see the consequences:

• Product complexity. The product gets cluttered - user experience confusing, technical complexity increased with special cases or “just this once” hacks.

• Roadmap by negotiation. Priorities are set through escalation and negotiation. If you put all ongoing activities next to each other, you’d struggle to explain why some of them made it through as top priority or how they connect to company goals.

• No coherent “no”. Nobody is clearly mandated to say: “This request makes sense locally, but it weakens the product or system overall”.

The result is a gradual drift away from a sharp value proposition and a clear architecture, towards a product that reflects internal politics more than user needs.

Example 3 – When roles overlap and nobody is clearly accountable

Another common pattern is when leaders have overlapping scope.

On the org chart, it looks mature and well-structured – roles like Head of Platform and Head of Architecture, or Group Lead and Head of X.

But when their responsibilities aren’t sharply defined, the day-to-day reality gets inefficient very quickly.

Alignment overhead increases. People add more syncs: 1:1s, pre-meetings, “quick catch-ups”.

Double work or no work. Two people are writing their own strategy, principles or roadmap, or proposal, and then have to merge them afterwards. Other times, each assumes the other will take the lead on a tricky decision, so nothing happens until someone escalates.

Teams get stuck in ambiguity. When roles overlap, teams are never quite sure whose call it really is. So they start to: check decisions with both leaders “just to be safe”. They spend more energy navigating opinions and less energy on moving the work forward.

This is what happens when we create titles without clear decision rights.
It doesn’t create a big chaos, but it does reduce effectiveness and slows delivery down.

Principles to Design Your Decision-Making Architecture

All these examples share the same root cause: ownership and decision rights were never deliberately designed.

Don’t let your decision system “just happen” - you probably won’t like the result.

Instead, treat decision-making as part of your architecture: something you can design, test, and improve.

Once you look at it that way, a few simple principles can help you put the right setup in place.

Principle 1 – One strategy, one owner

For every important area, there should be one clearly named person who owns the strategy and how decisions are made in that area.

But:

One owner does not mean one person decides everything.
It means one person is accountable for the decision system in that domain.

Their job is to:

• Set direction and constraints.

• Decide which decisions are delegated and to whom.

• Step in when there’s conflict or ambiguity.

When you don’t have one owner, you get “everyone influences, nobody owns”.
When the owner decides everything, you get a bottleneck.

Principle 2 – Push decisions to the lowest level with enough context

Good decision architecture follows a simple rule:

Leaders define direction and rules.
Teams decide how to get there.

Decisions should live where:

• The information is richest (close to users, systems, incidents).

• The consequences are felt (by the people who build and run the product).

Leaders and domain owners should be asking:

• Which decisions must stay at my level?

• Which decisions can teams make on their own?

• Do they have the right business information and context to make that call?

If small UX choices, tech approaches, and team-level prioritisation still routinely go to the CEO/CTO/board, you don’t have strong governance – you have a centralised anti-pattern.

Principle 3 – Clear boundaries of responsibilities

“Shared ownership” sounds healthy.
In practice, shared ownership without clear boundaries usually becomes blurred accountability.

You want statements like:

• “You own this domain; I own that one.”

• “You decide implementation; I decide which problem we solve first.”

• “You own reliability for this surface; I own scope and timelines.”

If you ask, “Who decides when you disagree?” and people hesitate, your boundary isn’t real.

Double work, and “we thought the other person would lead this” are all symptoms of ignoring this principle.

Principle 4 – Treat important things as components with owners and metrics

Some parts of your product and organisation are critical or chronically painful.

If something is important, repeatedly painful, and measurable, consider treating it as a separate component.

That means:

• Give it a clear boundary – what’s inside, what’s outside.

• Assign one strategy owner.

• Define a small set of success metrics.

For example, “Customer data integration” for new clients. Instead of being everyone’s problem (sales, implementation, ops, backend), you treat it as a component:

• Set one owner accountable for the end-to-end integration experience.

• Set metrics like time-to-first-sync or number of one-off scripts to show measurable progress.

You can apply the same thinking to other domains that you find business critical.

Principle 5 – One owner, many deciders, shared principles

You don’t want either extreme:

• Centralised decision making: one person decides everything.

• Chaotic decision making: everyone decides everything.

The middle ground:

One owner for the strategy and decision system.
Many people making decisions locally.
All using the same principles.

Those shared principles can be, for example:

• Product principles – who we build for, how we want the product to feel, what we won’t do even if asked.

• Architecture principles – how systems interact, expected uptime and reliability, how configurable or bespoke the system is allowed to become.

Over time, these principles become part of how people think – ground rules that teams follow almost intuitively when they decide what to do next.

Principle 6 – Make important decisions visible

Invisible decisions are a source of rework or blame.

You don’t need heavy process, but you do need a habit.

For meaningful decisions, capture briefly:

• What we decided.

• The key options we considered.

• Who decided and who was consulted.

• What we’re trading off.

You create a “log” for the decision thinking, so you can later see patterns and refactor how decisions are made.

5. Where to Start: Refactor Your Decision-Making System

You don’t need to fix decision-making with a big-bang reorganisation.
You fix it the same way you fix a complex system: find one painful area, change how it works, learn and repeat.

Here are some tips on how to start.

1. Pick one domain

Pick one domain that you find important or where you observe a continuous pain. For example:

• A part of the product where development feels slow.

• A new capability (onboarding, billing, integrations) that is cluttered and confusing.

• A platform or architectural area where everyone has opinions and complains.

2. Do a quick decision audit

For the last 2–3 months in that domain, ask:

• What were the 3–5 biggest decisions?

• Who actually made them? How did they get there? (escalation, board meeting, data …)

• Which ones went well, and which felt painful, slow or frustrating for the team?

• Were there hidden, conflicting principles at play (“move fast” vs “minimise risk”) that nobody named explicitly?

3. Apply “one strategy, one owner”

Appoint one owner for that domain.

Make it explicit that their job is to:

• Own the strategy and direction for that domain.

• Design the decision system: who decides what, and where.

• Define metrics that person is responsible to drive.

Write it down in one or two sentences so everyone understands it.

4. Decide which decisions move down

With that owner and the core team for the domain, walk through:

• Which decisions genuinely belong with the owner? For example, big trade-offs, cross-team conflicts, major bets.

• Which decisions should we move down to teams? For example, implementation, UX details, local prioritisation, experiments.

Check if teams have enough context and information to own those decisions.
If not, fix that: share metrics, strategy, or any business constraints.

5. Set a few principles as guardrails

Co-create a small set of domain principles.

For example: “We optimise for user experience. Clear, intuitive design is our differentiator, even if it costs us extra effort in implementation.”

In exceptional situations, you might need to break a principle – but that should feel exceptional: the owner is consulted, or the decision is clearly logged as a conscious deviation.

A simple test: If people can’t use these principles to make everyday decisions without asking for permission, they’re too vague.

Tighten, clarify, and iterate until teams can confidently decide and still stay inside the guardrails.

6. Make it visible

Create a one-pager for the domain. Summarise important points like:

• Domain name

• Owner

• Key teams involved

• Main decision boundaries (owner vs teams)

• 3–5 principles

• Key metrics (if relevant)

Share it on Confluence. Point to it in meetings. Use it when someone asks “who should decide this?”.

7. Add light decision logging

Capture the key decisions in 1–2 short paragraphs each: what we decided, why, who decided, and what we traded off.

Then, every now and then, review these with the owner and the teams:

• Are we escalating the right things?

• Are the principles actually helping teams decide on their own?

• Are we still too centralised, or drifting back into chaos?

If the logs turn out to be useful, keep the habit.
If they’re not adding value, change the format or frequency—but don’t go back to a world where important decisions leave no trace at all.

Closing Thoughts

You can’t scale your organisation on the same decision system you designed for Day 1.

If you let your decision system “just happen”, it will – but you probably won’t like the result.

Ask yourself:

Have we designed a decision-making system that matches our size, strategy, and reality?

If not, start where the pain is highest – the overloaded executive, the incohesive product area, the overlapping roles – and begin to redesign your decision-making architecture iteratively and deliberately, one step at a time.

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.

👉 If you found this useful, you might also enjoy my other articles on leadership, product strategy, and team dynamics:

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

If you’ve been in a Management Team long enough, you’ve heard this question. Big goals are set, the strategy looks sharp on slides, and the plan feels achievable.

But a few months later, deadlines slip, priorities shift, and frustration sets in. Three more months pass, the same thing happens again. Eventually, the strategy itself pivots, and the whole cycle restarts.

The common explanations are familiar: not enough resources, too much tech debt, too many dependencies. All of these can play a role, but they aren’t the root cause.

The deeper issue is the translation gap — the space between the dream at the top and the day-to-day work items at the bottom.

How Strategy Fades on Its Way to the Backlog

Big goals are born in MT meetings and boardroom slides. But while leadership spends its time shaping strategy,

business outcomes don’t live in the boardroom. They live in the backlog.

And the problem is: between the vision and the moment a developer picks up a ticket, the message gets reshaped again and again:

Each step is another round of broken telephone. Clarity blurs. Context gets lost. Sensitive details get softened. Gaps are filled with assumptions.

By the time a backlog item lands with a team, it often barely connects to the original goal. Work gets shipped, but it doesn’t move the business forward. Teams feel urgency — “This needs to be done by tomorrow” — but urgency isn’t the same as impact. Finishing it quickly doesn’t mean it addresses the core issue.

It’s like hitting the edge of the target instead of the bullseye: effort spent, but not full impact.

The result: energy spent, deadlines missed, and business plans slipping. Not because engineers can’t deliver, but because strategy doesn’t survive translation.

Scaling the Waste

When you have one small team, a translation gap might cost you a sprint. Painful, but manageable.

Now picture a company with 100 teams. Each one is a few degrees off. No single team is failing outright, but together those small misalignments snowball into missed quarters and plans.

And the more layers you have, the longer the telephone line gets — and the fuzzier the message becomes. That’s why large organisations often feel slow: the translation gap compounds faster than the company grows.

Culture as a Multiplier

Culture determines whether translation gaps get corrected or ignored.

In transparent cultures, teams feel safe to say: “This doesn’t connect to the bigger goal.” Concerns surface quickly, leaders hear the bad news early, and course-corrections happen before waste piles up. Miscommunication still happens, but it’s smaller and resolved faster. People can commit ambitiously because they know raising risks won’t get them punished.

In cultures of fear, the opposite happens. Progress gets sugarcoated. Promises blur as each layer colours the truth with polished updates instead of directness. Doubts are whispered in hallways, while official updates look safe. Engineers may see the real blockers, but if their voices aren’t welcome, leaders only learn the truth when it’s too late. Rigid, top-down roadmaps make it worse: people commit because they must, and communication turns into spin.

Transparency multiplies alignment. Fear multiplies waste.

The Leader’s Role in Closing the Gap

Leaders often underestimate how much of their job is translation. Setting the vision is only the start. The real work is making sure that vision can survive the long telephone line of portfolios, roadmaps, and backlogs without losing its meaning.

Here are some principles that help close the gap:

1. Fix the culture.

Create psychological safety so people feel comfortable speaking up when things don’t line up. Google’s research highlights psychological safety as the #1 factor in top-performing teams.

Listen carefully, show understanding. Model direct communication yourself by speaking plainly and being clear with the facts you can share. A practical way is to ask openly where things don’t connect and thank people for pointing it out. Group meetings, one-on-ones, or anonymous surveys can all help. When honesty is normalised, issues surface faster.

Way too often I’ve seen teams without psychological safety. Status updates looked polished, but real blockers were not raised. Communication became blurry and expectations drifted away from reality. The result — big delays, frustration and failing plans.

2. Simplify the chain.
Structure and clarity in the operating model are essential, especially as organisations grow. But every extra layer makes the telephone line longer and increases the risk of the strategy getting lost. Too many layers dilute the goal itself.

Be mindful of the balance. Cut unnecessary steps, shorten reporting lines, and give people enough autonomy to make calls without multiple escalations.

Watch out for roles with unclear responsibilities. This leads not only to duplication of effort, but also wasted time spent on alignment rather than progress.

You might have experienced situations where getting approval for a new tool requires five different sign‑offs. By the time the decision comes through, motivation has dropped and the relevance gone.

Simplify the chain. The simpler the chain, the clearer the message stays.

3. Clarity in communication (it is never too much).
A message that feels obvious in the boardroom can become vague two layers down.

Keep repeating goals until they stick. And use a plain and consistent language. Same phrases consistently across presentations, dashboards, and team updates.

Be consistent with terminology too. Business goals should have a clear and stable name. Initiatives should also have names that don’t change from one slide to the next. When labels shift, people get confused. When terms stay steady, the strategy becomes easier to follow.

For example, pin the top three goals to every company-wide deck, and make sure Jira epics or initiatives reference them directly.

Over-communicating clarity is better than letting silence create confusion.

4. Connect work to outcomes.
Backlog items only have real value when they clearly tie to business goals. The connection should be visible across every layer: from business goals to initiatives, from initiatives to roadmaps, from roadmaps to epics, and from epics to backlog items. When this chain is transparent, even the smallest ticket can be traced back to a meaningful outcome.

Explicit traceability is not bureaucracy — it prevents drift and keeps motivation high. People work harder and smarter when they know how their piece of the puzzle contributes to the bigger picture.

Consistency also matters. Use shared terminology across product, business, and engineering. If business calls it a “growth initiative,” product calls it an “epic,” and engineering calls it a “feature,” it causes confusion. It’s best to choose names that resonate with everyone and stick with them.

A practical step: set up your tools so this linkage is easy to see. For example, connect user stories to epics, epics to initiatives, and initiatives to top-level goals in your planning tool. Dashboards that show progress along this chain help leaders and teams speak the same language and see the same outcomes.

5. Keep communication data-driven.
Every time I see metrics and charts in a meeting, the discussion shifts. It becomes more objective, less biased, and less vague. Metrics ground conversations in evidence and make progress visible.

But data is not a replacement for dialogue — it should support it. Numbers need to be interpreted in context. Good leaders ask: What story does this data tell, and does it match what’s really happening on the ground?

When you keep the conversation data-driven, bias and emotions have less room to dominate and decisions become clearer.

Used well, data is a lever that increases alignment and effectiveness. It connects backlog items to real outcomes and helps everyone see whether the work is truly moving the needle.

Closing Thoughts

Delivery doesn’t fail because teams can’t ship. It fails because strategy doesn’t survive the journey from the boardroom to the backlog. The big goals blur, context gets lost, and thousands of small items drift just far enough off course to dilute the outcome.

Perfect alignment will never exist. But every step you take to close the translation gap pays back many times over.

When small backlog items line up with the bigger dream, they create compounding impact. That’s when business dreams start becoming reality.

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

Subscribe now

Access more product content on Lean Product Growth

They succeed because people believe in them.

As a leader, your role isn’t just to see the future — it’s to make sure your team can see it, feel it, and choose to walk there with you.

When Your Big Idea Lands Flat

You’ve had that spark of clarity. Maybe it came during a walk or a late-night brainstorm. You’ve just discovered a new workflow platform that could finally bring order to the chaos — automate the repetitive tasks and cut your team’s workload significantly.

In your mind, it’s a no-brainer: faster, better, more efficient.

You can’t wait to share it with your team.

So you step into the meeting, and announce: “Here’s the big idea. If we do this, we’ll unlock huge value.”

And then — silence. Someone cautiously raises a doubt. Another wonders aloud if this is just the latest in a long line of “new priorities.” A couple of polite nods suggest the message didn’t quite land.

Your idea might be strong. But your team isn’t there — not yet. And without their belief, even the greatest idea quickly fades as business as usual takes over.

That hesitation reveals there is a gap between your vision and your team’s belief.

Closing that gap doesn’t happen with a single speech or a polished slide deck. It happens step by step — in how you listen, how you show progress, and how you bring people along.

Here’s how.

Lesson 1: Start With Their Reality

Leaders often forget: while you’ve been connecting dots and thinking about the future, your team is fighting the present. Tight deadlines, bugs, customer escalations, or simply too much on their plate.

That’s why influence doesn’t begin with your vision. It begins with their perspective.

Ask questions. Listen deeply. What do they see? What’s blocking them today? What trade-offs feel impossible?

By starting here, you’re not only gathering insights that make your idea stronger — you’re showing respect. People are far more willing to move if they feel heard.

And if you can connect your vision to the problems they’re already fighting with, even better. Show them how tomorrow could be a little easier than today. But don’t jump too far ahead — your team doesn’t need a five-year utopia. They need to picture what changes in the next sprint, the next month or the next quarter.

Lesson 2: Plant the Seed Gradually

After you’ve listened to your team’s reality, the next step is to plant the seed of your idea.

Think of it like a gentle introduction rather than a one-time pitch. Mention the concept in a few different contexts, ask for opinions, and let it settle in. Give people the space to get used to it before expecting enthusiasm.

By surfacing the idea gradually, you make it feel familiar instead of disruptive. It’s not about pushing hard — it’s about making the change feel natural, almost inevitable.

And through these informal conversations, you’ll sense when the time is right to move forward and bring the idea to life.

Lesson 3: Find Your Early Adopters

Not everyone in your team is ready to jump into something new. Some are comfortable with the status quo — they might complain about the problems, but hesitate to risk trying a new solution.

But others lean forward. They’re curious, restless, or simply too frustrated with the current way of working to keep doing it the same old way.

Those are your early adopters. Start with them.

Give them space to test your idea in a smaller, safer way. Encourage them to experiment, adapt, even fail — and let them shape the first iteration. When progress becomes visible, these early adopters turn into your champions. They’ll share their experience in a language the rest of the team trusts far more than your presentation could.

Lesson 4: Start with a Small Pilot

Once you’ve got your early adopters on board, the next step is to set up a proof of concept—a small, manageable pilot that can show real results quickly. Think of it as a low-risk experiment that gives everyone a glimpse of what success could look like.

By starting small, you’re making the change feel less intimidating and more achievable. You're giving the team a chance to see tangible progress without the pressure of an all-or-nothing rollout. It's a way to build momentum naturally.

In other words, a pilot not only proves the concept—it gives your team a taste of success. And once they see those early wins, they're much more likely to get fully on board.

Lesson 5: Share the Wins Through the Team’s Voice

Once your small pilot has shown some real results, it’s time to share those early wins with the rest of the team.

Let your early adopters do the talking.

When the message comes from their peers—people who have actually used the new approach and seen the benefits—it feels much more genuine and relatable.

Encourage those early adopters to share their experiences in team meetings or informal chats. They can talk about what’s improved, what they’ve learned, and how it’s made their work easier or more effective.

This kind of peer-to-peer sharing can be much more effective than any polished slides or a top-down communication.

Lesson 6: Scale Gradually and Keep Iterating

When your early wins are visible and your champions are spreading the word, it’s time to scale. This doesn’t mean scaling overnight — it works best in stages.

Begin with one or two teams, learn from their experience, and then expand across the wider organization. Each step strengthens credibility and lowers the risk of a failed “big bang” rollout.

And remember: scaling isn’t about rolling out a “finished” idea. It’s about growing and refining it as you go. Keep feedback loops open. Ask what’s working, what’s frustrating, and where the idea can be improved.

Each iteration makes the solution stronger and increases ownership at every level.

Final Thoughts

In the end, turning a big idea into a shared reality is all about listening, planting the seeds, finding those early believers, and scaling thoughtfully. It’s not about rushing or pushing—it’s about guiding your team step by step until your vision becomes their dream.

And remember:

Belief is the real test of leadership.

Ideas are easy. Belief and action are what make them real.

👉 Want more practical leadership insights for scaleups? Subscribe to Lean Product Growth for regular updates on building and scaling a successful product organization.

Subscribe now

This thought often comes to mind when I’d look at a roadmap for the first time.

A roadmap isn’t just a delivery plan — it’s a cultural scan. Look closely, and it tells you a lot more than what’s being shipped. You can read:

• Decision-making style – Is it driven top-down, or do teams genuinely shape what gets done?

• Trust levels – Do leaders trust teams to commit openly, and do teams trust leaders to stick with priorities?

• Political balance – Which initiatives get the spotlight, and which quietly disappear?

Clues Hidden in Every Roadmap

An org chart shows how your company is supposed to work. A roadmap shows how it actually works.

Here are some clues hidden in every roadmap.

1. How Much is in it

Is the roadmap crowded with initiatives, or does it focus on a small number of deliberate bets?

What it reveals:

• An overloaded roadmap signals a reactive culture, attempts to satisfy too many stakeholders, or weak prioritisation. In practice, many of these items will likely remain unfinished or only partially complete as the team tries to tackle them all at once.

• A focused roadmap Indicates strong product leadership, clear trade-offs, and the confidence to say “no” when necessary.

An overloaded roadmap creates inefficiency. Stakeholders stop believing commitments, and teams often feel demoralised by carrying half-done work from one cycle to the next. A focused roadmap builds credibility, keeps energy behind the most important priorities, and increases the odds of delivering meaningful impact.

2. Time Horizons

Does the roadmap lay out detailed plans 12–18 months ahead, or does it focus only on the next quarter?

What it reveals:

• A very short-term (only the next sprints) roadmap indicates agile maturity and focus on learning. However, if there’s zero view beyond that, it often means reactive planning and no strategic clarity. This creates uncertainty for stakeholders and makes it hard to align resources.

• A detailed yearly plan may be necessary in regulated or highly predictable contexts. However, in many cases it’s a sign of top-down, milestone-heavy thinking that sacrifices flexibility and locks teams into outdated priorities.

• A balanced approach is an example of an effective roadmap. It illustrates clear, more concrete plans for the next quarter (where execution is in focus), while keeping longer-term items more strategic and less fixed. This ensures teams have both direction and room to adapt.

A roadmap’s time horizon shows whether the organisation is optimising for control or adaptability — and whether it’s being honest about the uncertainty it faces.

Too short, and you risk drifting without direction. Too long, and you risk building the wrong thing very efficiently.

3. Language

Are items described in broad, generic terms like “Enhance platform capabilities”, or in clear, outcome-focused language like “Reduce mobile checkout time from 90s to under 45s”?

What it reveals:

• Vague language is often a sign of fear of commitment, internal politics, or a desire to keep all stakeholders happy without making trade-offs visible. It can also signal lack of clear focus and lack of clarity on what the team wants to achieve.

• Specific, outcome-oriented language suggests high trust, alignment on priorities, and a willingness to be held accountable for results. Teams understand the problem they’re solving and the value it delivers.

The way work is described reveals the psychological safety and clarity within the organisation. Clear, measurable language makes it easier to prioritise, track progress, and know when something is truly done. Vague descriptions keep everyone busy — but make it hard to tell if you’re moving the needle.

4. Work Mix

Does the roadmap include a balance of new features, maintenance and technical improvements — or is it almost entirely focused on shipping new features?

What it reveals:

• A Balanced Mix shows leadership recognises that sustainable delivery requires continuous investment in product health and stability. It also signals an understanding that reserving capacity for experimentation and discovery is essential — both to keep the product differentiated today and to unlock new opportunities for tomorrow.

• Feature-only means that progress with new features takes priority over long-term value. With no dedicated space for maintenance, debt reduction, or exploration, the product risks slowing down over time and missing chances to create differentiated solutions.

Focusing only on short term wins almost always backfires at some point — and usually at the worst possible moment, such as during a major release or growth push. A roadmap that consistently allocates time for technical improvements or innovation has much higher chances for long term success.

5. Silos vs. Collaboration

Is the roadmap divided into separate streams for components (e.g., frontend, backend, infrastructure), or is it organised around shared outcomes that deliver value end-to-end?

What it reveals:

• A component-focused roadmap suggests siloed ways of working, where each function optimises its own output without a clear view of the overall outcome. This often leads to delays, unnecessary handoffs, and a lack of accountability for whether real value is delivered.

• An Integrated roadmap indicates cross-functional collaboration, with teams aligned on solving problems and delivering value as a whole. Work is framed around customer or business impact, not internal boundaries.

When work is planned in silos, teams may look productive on paper but fail to deliver meaningful results. A roadmap centred on outcomes fosters alignment, reduces waste from handoffs, and ensures that every function contributes directly to value creation.

6. Outcome Framing

Does the roadmap list outputs like

“Launch new reporting dashboard”, or does it describe problems to solve and results to achieve, such as

“Enable managers to identify performance issues within 24 hours”?

What it reveals:

• An output-driven roadmap means that success is measured by shipping deliverables, regardless of whether they create value. This mindset often leads to teams hitting deadlines but missing the real needs of users or the business.

• An outcome-driven roadmap shows that the focus is on the impact, value, and learning gained from the work, and on how each initiative connects to bigger strategic goals. It shows that the team understands why they’re building something and leaves space for iterating on the how. It encourages exploration for different solutions options that may deliver greater results than the original idea.

Framing shapes behaviour and changes team’s focus. If the roadmap speaks in outputs, teams will optimise for outputs — delivering what was asked for, but not necessarily what was needed. Outcome-focused framing, especially when tied to broader organisational goals ensures that delivered work moves the company meaningfully forward.

When the Roadmap Isn’t Grounded in Reality

Not every roadmap reflects how things actually work. Some are designed to look tidy for investors, customers, or executives — polished artefacts that tell a simple story but leave out the messy truth.

You can often recognise one of these when:

• Work is evenly distributed across teams, as if by design.

• No delays, trade-offs, or shifts in priorities are visible.

• Every item is framed as equally important.

In these cases, the real working roadmap usually exists elsewhere in a less polished form. But even the curated version still tells you something valuable: it shows the image the organisation wants others to believe about its priorities and culture.

How Leaders Can Use This Knowledge

If you’re a leader, you can put this roadmap-reading skill to work in two ways:

1. Audit your own roadmap
Step back and look at it like someone seeing it for the first time — maybe a new hire or an external partner.

• What story does it tell about your culture, priorities, and decision-making style?

• Does it reflect the organisation you are, or the one you want to be?
  If there’s a gap, that’s your cue to adjust — not just the roadmap, but the way you set priorities and communicate them.

2. Decode roadmaps in new environments
When joining a new company or taking over a team, ask to see their roadmap early.

• How is work framed — outputs or outcomes?

• Who owns what, and how balanced is the mix of work?
  You can often learn more about the real dynamics, decision-making habits, and cultural tone from a roadmap than from any onboarding pack or company presentation.

Your roadmap is more than a plan — it’s a mirror. Whether you like it or not, it’s telling a story about your priorities, your culture, and your leadership style.

The only question is: are you happy with the story it’s telling?

👉 If you found this useful, you might also enjoy my other articles on leadership, product strategy, and team dynamics.

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

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

But far too often, it’s treated as a technical concern, not a strategic one.

In reality, technical debt is a business cost — one that compounds silently until it blocks product progress.

Software Is More About Maintenance Than New Development

👉 Data shows that 70–80% of a software product’s total lifecycle cost goes to maintenance.

Not new features.
Not exciting launches.
Just… keeping the current system alive.

That includes:

• Troubleshooting fragile code

• Rewriting messy logic

• Updating dependencies and adapting to changing APIs

For every line of code you ship, expect to spend five times more effort maintaining it over time than it took to build.

Size and Software Complexity Matter

As complexity builds, teams slow down. And because the slowdown is gradual, it often goes unnoticed — until it’s too late.

Every new feature means more code.
And more code means more effort to maintain.

This is why early development feels fast: there’s no legacy, no detours.
But as the system grows, so does the burden. Developers inherit old decisions. Logic becomes tangled. Even small updates start to feel risky and slow.

The more complex the architecture, the steeper the growth curve in effort required.
Teams want to build forward — but are constantly pulled back to fix the past.

👉 Studies show that maintaining poor-quality code can require 2–3× more effort than working with clean, well-structured systems.

So Why Do We Delay It?

Because the cost of not addressing tech debt feels invisible — until it suddenly isn’t.

Teams push it aside because:

• “We’ll fix it next sprint” (but we don’t)

• “New features have a priority” (but they take longer each time)

• “It’s not urgent” (until we’re blocked)

The longer we delay, the harder — and more expensive — it is to fix.

Making the Call: Refactor, Rebuild, or Leave It?

When tech debt builds up, you’re not facing a code issue anymore — you’re making a strategic call.

Here are the three most common paths forward:

• Do nothing, accept it and leave it as is.

• Refactor parts of the system

• Rebuild in parallel

Each path has trade-offs. What you choose depends on timing, team maturity, product lifecycle, and business goals.

👉 Want the full breakdown?

Read the deep dive here: Technical Debt Decision-Making: Refactor, Rebuild, or Stand Pat

Have you made a business case for refactoring or rebuilding?
What worked? What didn’t?

Reply or comment — I’d love to hear your examples.

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

Most of my toughest weeks as a leader didn’t come from poor execution—they came from failing to manage up.

It wasn’t about doing better work. It was about making the work visible, understandable, and assuring that things were under control.

Not every manager will have the time or space to dive deeper and understand the nuance behind your decisions.

The good news? It’s a growth opportunity. These moments push you to sharpen how you communicate, build trust through clarity, and grow your influence by connecting the dots consistently.

Managing up isn’t about politics. It’s not about playing games or performing for promotion. It’s about communicating with intent. It’s strategic storytelling: ensuring your impact is seen, your direction is clear, and your team’s work continues to move forward.

1. Communicate Regularly and Reliably

I’ve seen leaders clean up internal chaos in just two months—only to face skepticism in the management room.

Why?

Because they forgot to tell the story. They focused entirely on solving the problem and assumed results would speak for themselves.

But senior leaders don’t always have the luxury to wait for the full picture. And when they don’t hear progress, they often assume there isn’t any.

When you don’t communicate on time, decisions get made based on assumptions. Your brilliant progress might go unnoticed. Your great idea might be missed. The team’s success can stall—not because of performance, but because of perception.

Communicating progress isn’t extra work. It is the work.

Even if no one is asking, create visibility. It’s your responsibility.

A 1-on-1 update, a concise email, a short Slack post, or a one-slide summary—choose whatever fits the context.

Align early on how your manager wants to stay informed. Ask:

“What’s the best way for you to stay updated—weekly summaries, monthly highlights, or something in between?”

Make it easy for them to digest the update and see your impact—and even easier for them to share it when you’re not in the room.

2. Bring Just Enough Detail

When you share too little, your manager fills the gap with assumptions.

When you share too much, you risk overwhelming them—or losing their attention altogether.

The skill is in calibrating just enough.

Start with the outcome and your rationale. Let their curiosity pull you deeper if needed.

“We considered three options. We’re leaning toward Option B. This is fastest to implement, and lowest cost. Happy to go deeper if you’d like to unpack it.”

If you’re unsure of how much to share, just ask:

“Was this too high-level or too detailed? What would make it more useful for you next time?”

Remember: your goal isn’t to offload your entire thought process—it’s to build clarity and trust.

3. Don’t Try to Impress—Try to Inform

You live the details. Your manager doesn’t.

Your job is to elevate the signal from the noise.

They don’t need the full story—they need the headline, the why, the next steps. And they need your level of confidence to bring everything to green.

Don't aim to impress with technical depth. Don’t make drama out of the challenging problem you’ve managed. Aim to inform with clarity.

Instead of:

"It’s really complex and challenging. We’ve been firefighting 2 days. Let me walk you through everything.

Say:

"We hit a blocker that affects our timeline. Here’s what we’re doing about it. We have high confidence that this will bring things on track.

Your credibility goes up when you keep it simple and grounded.

4. Show Ownership and Accountability

Things won’t always go as planned. Your manager knows that. What they want to see is whether you’re in control, and confident in how to move forward.

If you hit a blocker, acknowledge it. That’s normal. But don’t stop there—show that you're thinking ahead. What are the options? What’s your next move?

Instead of giving excuses or blaming someone else

“We didn’t make progress because X didn’t deliver and Y failed.”

Show how you plan to solve the problem.

“We hit a blocker. Here’s what we’re doing to resolve it. We may need a decision from X to proceed.”

Own the resolution, even if you don’t own the problem. That’s what accountability looks like.

And if you don’t feel on top of the situation or you are out of options—say so. Earlier is better. Ask for help clearly and calmly:

“We’re hitting repeated blockers, and I don’t think we can fully resolve them internally. I’d appreciate any input or ideas you might have.

It’s not a sign of weakness. It’s a sign of leadership maturity—naming the problem, proposing a path forward, or asking for help when necessary.

5. Keep Your Composure—Even When It’s Hard

This might be the most transformative habit you can build for long-term leadership success:

Don’t match emotion with emotion.

One of the most powerful lessons from a recent leadership program was this:

Ego meets ego = explosion. Ego meets calm = clarity.

Mature leadership means mature communication. Even when a conversation gets tense. Even when you're challenged unfairly. Your tone sets the tone. And your ability to stay calm when others aren’t is what builds trust over time.

Stakeholders, execs, and team members won’t always react positively. But that’s not your cue to mirror their energy. It’s your moment to steady it.

Hold this mindset close:

“I do the best I can. I don’t take it personally. I’m here to help.”

This is what separates reactive managers from grounded leaders. It’s not about suppressing emotion—it’s about choosing response over reaction.

If you struggle with this, start by reconnecting to why you’re in this role. You care about outcomes. You’re here to build. And not every challenge is yours to absorb.

Staying grounded doesn’t just improve the moment—it defines your presence as a leader.

6. When Your Ideas Don’t Land, Be Strategic

Sometimes you have a brilliant idea, but you can already feel the resistance in the room.

Don’t push. Pause. Reflect. Look for the gap.

The timing might be wrong. The context might be missing. The trust might not be there yet.

Don’t be pushy or let your ego get bruised when things don’t click immediately. Be strategic in how you build alignment. Strong ideas need strong delivery to land well.

Instead of:

"This is clearly the right path. I don’t understand why we are not doing it."

Say:

"I get that this might feel early. Would it help if we tested this idea on a small use case and learned from it together?"

Start small. Let people see the value first, not just hear about it. Be strategic in how you build alignment.

Managing Up Recap

No matter how capable or empathetic your manager is, they can only make decisions based on what they know—and what they know often comes from you.

If managing up feels awkward or unnatural, you’re not alone. It’s rarely taught. But it’s a skill that’s learnable.

Here are the essentials to keep in mind:

• Make your work visible. Don’t wait for the results to speak for themselves—it might be late.

• Adapt to their style. Communicate in a way your manager can absorb quickly and act on.

• Aim to inform, not impress. Keep it clear and to the point.

• Own the resolution. Even if you don’t own the problem, show how you’re moving forward.

• Ask for help early. It shows maturity, not weakness.

• Stay calm when it’s hard. Your tone sets the tone—especially under pressure.

• Be strategic when ideas don’t land. Timing, trust, and delivery matter just as much as the idea itself.

  Managing up isn't just a skill—it’s a leadership accelerator. The more intentional you become, the more your impact compounds.

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

In early-stage companies, scrappy workflows are a strength, simple slack messages, spreadsheets are sufficient. But once a company starts to scale, those same workflows become friction. Coordination slows. Quality drops. People duplicate effort or lose track of who’s doing what.

Now, with AI reshaping the landscape, many companies are turning their attention inward. They’re asking: How can we improve internal productivity without adding overhead?

The answer isn’t more tools. It’s applying product thinking to how your business runs.

When you treat internal operations like a product—with users, feedback loops, testing, and continuous improvement—you don’t only digitize. You simplify. You identify hidden gaps and unlock opportunities. And you build effective systems that scale.

This article shares how to bring product principles into your internal operations so your company can scale with clarity instead of chaos.

Recognize Your Superpower: Your Users are Right Here

One of the biggest advantages of building internal tools?
Your users are sitting right next to you—or at worst, one Slack message away.

You don’t need formal research studies or stakeholder discovery calls.
You don’t have to navigate complex client org charts to arrange a call with a user.
You have direct access to the people you're building for—every day.

It’s a product manager’s dream: a direct line to your audience, in their own environment, every single day.

Bring the user into the process. This makes the development much more effective, the adoption more organic.

• Co-create user journeys to uncover friction points.

• Share mockups and wireframes for validation.

• Run quick feedback sessions.

• Define clear success criteria (not just "it works").

• Track real adoption, not just release dates.

Apply the same rigor you'd use for customer-facing products. You'll earn deeper engagement and build trust across teams.

Start With Discovery: What’s Actually Happening in Your Operations?

Many companies digitize their operations by taking what already exists and building a tool around it. They might hire a consultant to collect process documentation and define product requirements out of it.

That’s a mistake.

Before you automate or rebuild anything, understand the real workflows. Not the ones written in documents, but the ones happening in chats or email threads.

Start with structured discovery:

• Shadow internal users: Observe how people actually do the work. Where do they get stuck? What do they skip?

• Map the journey: Visualize the end-to-end flow. Where are the delays, handoffs, or points of failure?

• Surface pain points: What slows people down? What do they avoid doing? Where are they relying on ad-hoc fixes?

When we started our discovery, we uncovered huge opportunities—gaps and inefficiencies that had never been named. People were making the same decisions twice, doing work that could easily be automated, or improvising their own solutions to navigate unclear processes.

This is where product thinking shines: you're not gathering “requirements”—you’re observing user behavior, uncovering unmet needs, and spotting opportunities to simplify.

And just like with external products, what you learn here will change how you build.

You could even realise that the biggest win isn’t automation but clarity.

UX Matters - Even Internally

Internal products often don’t receive the same level of care as customer-facing ones. They rarely have good UX, and they’re expected to “just work.”

After all, your users are your colleagues. They’ll tolerate friction and adapt.

Maybe.

But if you believe quality and UX matter for external product adoption, why wouldn’t they matter just as much internally?

Internal users are still users. If a product is unclear, unreliable, or difficult to use, they’ll find workarounds—or stop using it altogether.

Yes, you should release fast. But speed isn’t an excuse for poor experience.
A buggy internal tool won’t cause churn—but it will damage trust.
And once that trust is gone, adoption stalls and motivation fades.

Here’s what you’d need to keep in mind:

• Design matters. Not because it needs to look pretty—but because clear, simple flows make a tool usable from day one.

• Early adoption is fragile. If the first release disappoints, re-engagement is 10× harder.

• Momentum compounds. Each small, reliable release builds confidence—and lowers resistance to change.

Treat your colleagues like users you need to motivate and inspire.

Because when they trust what you’re building, they won’t just use it, but improve it with you.

Simplify Before You Build

It’s tempting to custom-build internal tools that mirror every edge case and replicate all the complexity of current processes.

But many of those processes aren’t truly unique—they’re just undocumented, inconsistent, or unnecessarily complicated.

The goal isn’t to rebuild the mess in software. It’s to simplify and systematize the work behind it.

Start by asking: Is the problem the process—or the lack of one?

Before you write a single line of code, try this:

• Clarify the workflow: Can it be simplified or standardized before being digitized?

• Borrow what works: Lean on proven patterns and best practices instead of reinventing everything.

• Avoid overengineering: Don’t automate what you can simply eliminate.

The best internal tools aren’t the most complex—they’re the most clear and useful.

Momentum Is the Multiplier

The early stages of digitizing operations can feel painfully slow. You’re aligning stakeholders, untangling messy workflows, testing early versions, and constantly fixing what breaks.

But then something shifts.

Once internal users start seeing real improvements—faster approvals, smoother handovers, fewer manual steps—momentum begins to build.

And this changes everything.

Momentum builds trust. Trust drives adoption. And adoption creates pull instead of push.

Suddenly, teams are volunteering to be part of the next pilot. They’re suggesting their own use cases. Users are proactively sharing feedback. Your internal product shifts from being “just another tool” to becoming essential to how the business runs.

Staying patient is important—but you can also actively build momentum.

• Share progress: Highlight wins—time saved, errors reduced, increased adoption. These metrics fuel motivation and confidence.

• Be responsive: You should not build everything people ask for. But when you act on feedback, make it visible. “You asked for X—we delivered it this week.”

• Show what’s next: Don’t just demo what’s done. Share your vision for what’s coming. Paint a clear, realistic picture of how things will improve.

You don’t need perfection—just visible progress.

When users can see that progress and believe in the future you’re building, they become your champions.

Closing Thoughts

Digitizing internal ops is more than building a tool—it’s a rare opportunity to make your company run better.

You’re in an exceptional position: your users are close, your impact is direct, and the complexity is real.

Apply product thinking, and you won’t just ship a tool—you’ll build clarity across teams, surface what really needs fixing, and create momentum.

Let the product do what it does best: simplify, scale, and make your COO breathe a little easier.

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

Last week I attended a CPO summit.

There wasn’t a single session, hallway chat, or panel that didn’t mention AI. Whether the topic was product operations, UX design, growth, or company vision — AI came up. Not as a distant trend, but as an urgent reality.

The transition is real.

CPOs everywhere are under pressure to "bring AI into the product" — but too often, that leads to rushed experimentation without a clear strategy, or worse, AI features that don’t help the user or the business.

So how do you know where AI actually makes sense?
Where should you invest — and where should you hold back?

What follows is a set of practical principles and decision patterns to help you evaluate whether an AI initiative is worth pursuing — and how to make sure it actually delivers value.

Let’s dive in.

If you're just beginning your AI journey, you might find this helpful: How to Bring AI Into Your Product — a guide to responsible adoption and key strategies for getting started.

AI Can’t Promise Accuracy

AI models (especially language models) are inherently probabilistic.

This means that you can feed them the same input twice and get two different outputs. They don't follow hard logic rules, and they make mistakes.

This means that AI is not suitable for use cases where determinism and correctness are non-negotiable. If your product needs to deliver a precise number, a legal decision, or any financial action, AI should not be in charge.

What it's great for is helping people start faster — with a draft, a suggestion, or a "good enough" shortcut that saves time. Think for example about:

• Predicting user churn

• Flagging anomalies in large datasets

• Identifying patterns even in high-stakes environment like medical scans

• Suggesting replies in support or sales

These are scenarios where “close enough” adds real value — and where human review or intervention remains part of the loop.

✅ Use AI when the outcome can be reviewed, edited, or safely ignored
❌ Avoid AI when the output must be exact, consistent, or legally or financially binding

From Click-Driven to Conversational UX

One big shift AI introduces is how users interact with your product.

Traditional UX relies on click-driven behaviour and using buttons, forms, filters, dropdowns. This works, but it's rigid — especially for complex tasks. AI, on the other hand, enables users to express their intent in natural language:

“Show me my most profitable customers from Europe last quarter.”

This doesn’t mean every product should suddenly become a chatbot. In fact, pure chat interfaces can frustrate users. But AI lets you combine structured and conversational input. This results in shorter paths to outcomes for users.

It’s time to rethink your UX interface. The key questions to ask:

• Where are users doing repetitive or multi-step tasks just to express intent?

• Can we collapse that into one input field or a flexible assistant panel?

✅ Use AI to reduce friction in complex or repetitive flows
❌ Don’t over-rely on chat as the only interface — mix patterns thoughtfully

AI Accelerates Early UX Exploration

In the context of UX, one big efforts is spent on early translation of ideas into mockups, flows, or prototypes. This is where AI is starting to make a real difference.

Today’s tools like Lovable, Galileo can:

• Generate wireframes and layout suggestions from a simple feature description

• Propose user flows based on goals or natural-language prompts

This is a major unlock for founders and early-stage teams looking to go from idea to testable landing page in a matter of hours and without needing to hire a designer.

For designers, these tools act as collaborators — helping them generate alternatives, explore directions, or simply get first ideas flowing.

These tools for sure won't replace designers — but they reduce the time from idea to first draft.

✅ Use AI to explore and prototype faster
❌ Don’t bypass design thinking — use it to accelerate, not replace your team’s process

AI Shines in Analyst Work and Unstructured Inputs

PMs, analysts, support agents, and operations teams all spend huge amounts of time making sense of unstructured or noisy data: analysing user feedback, interviews notes, support tickets, requirements documents, etc.

These are the kinds of tasks AI handles very well:

• Summarizing NPS comments

• Structuring product feedback, e.g. grouping by theme

• Extracting next steps from a discovery transcript

• Translating meeting notes or requirements documents into draft user stories

In fact, tools like Atlassian Jira already offer AI features that generate user stories or break them into subtasks automatically. This is a strong signal that this shift is already underway.

In these scenarios, AI doesn’t replace the human — but amplifies significantly their speed. It’s like a quick, tireless analyst in your team able to scan volumes of content instantly.

For CPOs, this is one of the fastest ways to create internal leverage. Instead of tasking a team with “read through 300 survey responses,” give them a model-assisted dashboard that organizes and prioritizes the results.

✅ Use AI to make qualitative data more actionable
❌ Don’t expect it to replace human judgment

Deep Research and Strategic Thinking

One of AI’s most valuable — and still underused — strengths is its ability to support deep research and strategic preparation.

AI can process and synthesize large volumes of fragmented, unstructured information and help you move toward strategic clarity. Think about market trends, competitor websites, internal strategy documents, customer interviews, and support tickets.

It won’t create your strategy for you. But it gets you to the thinking part faster. Instead of spending hours gathering inputs and making sense of them, AI handles this automatically, so you can focus on analysis, judgment, and decisions.

Tools like ChatGPT (Pro) and Claude now make deep research workflows widely accessible — even without a dedicated data or research team. Such tools can:

• Upload and analyze documents like interviews, strategy decks, and product notes

• Summarize and compare long-form content across multiple files

• Scan the web for relevant, publicly available information

• Integrate with internal knowledge bases or systems

• Connect all this information to help answer complex, strategic questions

✅ Use AI to compress and structure large volumes of input
❌ Don’t rely on it to generate strategy — use it to prepare, not decide

AI Reduces Human Time, But Increases Infrastructure Cost

AI is an accelerator — but it doesn’t come for free. Many AI models, especially those used for open-ended generation (like language models that respond to prompts or create content), can be compute-intensive and drive up infrastructure costs.

But that shouldn’t be a blocker.

More companies are realizing that the return on investment often outweighs the cost. As one product leader put it:

“I can now easily justify a business case for using AI with positive ROI to the CEO.”

Where AI creates the most ROI is

• Ssaving hours of manual work

• Improving quality of your decisions

• Accelerating product adoption and improving competitiveness

✅ Measure ROI and invest where you get business benefit
❌ Don’t scale AI features without tracking benefits or costs visibility

AI Raises the Bar for Security and Compliance

In highly regulated environments — like healthcare, finance, or government — introducing AI is far from straightforward. It’s not just a product decision; it’s a compliance and risk decision.

AI can raise serious concerns around:

• Data security and privacy

• Model hallucination and output accountability

This doesn’t mean AI should be off the table — but it does mean that security and privacy must be part of your AI strategy from day one.

For CPOs, that means partnering early with legal, compliance, and security teams to:

• Choose models and vendors that support on-premise or region-specific deployment if needed

• Avoid passing sensitive or regulated data into prompts unless fully anonymized

• Be transparent about where and how AI is used, especially in customer-facing workflows

✅ Build AI features with security, privacy, and accountability in mind
❌ Don’t treat AI like “just another API”

Wrapping Up

AI isn’t magic — it’s just a different set of tools. And like any other tool, it requires judgment, experimentation, and critical thinking.

If you start testing AI in your product workflows, you might increase your confidence — or you might find its limitations more quickly than expected. Both outcomes are useful.

But ignoring it is not an option.

Because AI is reshaping how users interact with products, how teams work, and how companies compete. It's changing expectations around speed, personalization, and productivity — whether you’re ready or not.

You don’t need to chase every trend. But you do need to understand the capabilities, limitations, and implications of AI — and make intentional decisions about where to use it, where to avoid it, and where to explore.

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

Then you step away.

And suddenly—momentum stalls. Decisions pile up. Priorities blur. The clarity you worked so hard to build begins to fade.

This is a common challenge—even for great leaders. Success is still too dependent on their presence. It’s because the system around them hasn’t been designed to operate without them.

What’s missing isn’t effort or skill — it’s System Leadership.

System Leadership – From Operator to Architect

System leadership is the shift from solving problems yourself to designing the conditions in which problems get solved—consistently, and without you.

It’s about shaping the environment where decisions get made, priorities stay clear, and execution keeps moving—even when you're not in the room.

A system is the sum of people, processes, culture, and tools that together determine how outcomes are produced.
Every team operates within a system—whether it was designed intentionally or not.

Traditional leaders operate the system: they drive progress, remove blockers, and solve problems themselves.

System leaders take a step back. They don't just run the system—they architect it.
They ask:

• Where do things typically break down?

• What rituals, tools, or constraints could help the system run more smoothly?

• How can clarity and accountability persist without me?

They don’t scale by doing more.
They scale by building systems where effectiveness is the default — so that progress continues even in their absence.

That’s the essence of systems leadership: making yourself obsolete—so the system can succeed on its own.

A Few Lessons from System Leadership

Here are five mindset shifts that show what systems leadership looks like in practice — whether you're leading a team, a product, an organization, or a cross-functional initiative.

Lesson 1: Your Product (or Team) Is a System

A product isn’t just a backlog or roadmap — it’s a living system.
It evolves as customers change, as teams grow, and as strategy shifts.

And living systems need care: feedback loops, clear structure, shared context, and cultural alignment.

That’s why planning alone isn’t enough. Great leaders are systems thinkers.
They don’t just ask, “What’s the next feature that brings value?” But rather:

“What needs to be true for this team to keep delivering value — even when I’m not in the room?”

That’s how you scale. Not just your product, but your impact.

Lesson 2. If You’re Always in the Loop, You Don’t Have a System

If your team can’t move forward without checking with you first, you’re not leading effectively — you’re causing a bottleneck.

System leaders design for autonomy.

They ensure priorities are clear, responsibilities are defined, and context is shared early and often.

When decisions are distributed, speed increases — and people grow.

Lesson 3. Good Systems Make Average Days Look Great

Long-term scale doesn’t come from bursts of effort — it comes from consistent, compounding execution.

System leaders build the conditions where momentum is sustainable:

• Strategic priorities are visible and aligned across teams

• Dependencies are clear and actively managed

• Feedback loops ensure learning happens in real time

In a system like this, progress isn’t exceptional — it’s the default.
Because the system is designed to keep moving, even when no one’s pushing.

Lesson 4: Don’t Scale Chaos — Scale What Works

As a company grows, messy workflows start to multiply.

If you scale before fixing inefficiencies, you don’t accelerate progress — you accelerate chaos.

System leaders pause to ask:

• What’s actually working here that we can make repeatable?

• What’s not working — and needs to be simplified or redesigned before we grow further?

They identify what works — and turn it into repeatable patterns.

Scaling doesn’t start with adding more people or process.
It starts with fixing what’s broken — and doubling down on what works.

Lesson 5: Culture Is the Invisible System Behind How Work Gets Done

Culture isn’t just how people feel — it’s how they behave under pressure, how they make decisions, and how they treat each other when no one’s watching.

It shows up in meeting dynamics, communication tone, how feedback is given, and how conflict is handled.

System leaders know these patterns don’t emerge by chance.
They can be shaped: by incentives or processes— the invisible structures that guide everyday behavior.

If your system tolerates blame, silence, or burnout — that is your culture.

It’s not what’s written in your values slide, but what happens when things get hard.

Recognizing the Signals is Where System Leadership Starts

If the lessons above reflect the mindset of a systems leader, the examples below show where that mindset begins: in the patterns already playing out around you.

Start observing those patterns with intent, and you’ll uncover opportunities to redesign the way your team works. Here are a few common signals to look for:

Prioritization Becomes a Weekly Argument

If every sprint planning or check-in turns into a debate about what matters most, you don’t need a better agenda — you need a clearer system.

Define how priorities are set and what trade-offs are acceptable. A shared model or link to OKRs will increase focus and clarity for everyone.

Every Release Feels Like Firefighting

Rushed launches, last-minute fixes, and unclear handovers are signals that your release process isn’t working well.

A system leader doesn’t treat these as isolated mistakes—they see them as signals that the process needs redesign. They introduce simple, repeatable structures—like checklists, pre-launch reviews, or shared release rituals—to make shipping smoother, safer, and more consistent.

Urgent Requests Constantly Disrupt the Plan

Unplanned work derails your focus not because it’s unexpected — but because it has nowhere to go.

System leaders don’t just say “no” more often—they redesign the system. They create dedicated tracks for triage, an escalation protocol, or an ops function to protect the core team.

Customer Feedback Doesn’t Guide Decisions

When customer insights are scattered across tools and anecdotes, they can’t shape product direction.

System leaders create a structured flow: tagged feedback, regular voice-of-customer reviews, or a central source of truth. The goal is streaming an input into the system so decisions are grounded in reality, not assumptions.

Too Much Time Goes to Manual, Repetitive Work

If your team is spending hours on repeatable tasks, your system is quietly leaking capacity.

You don’t need more people—you need a better system. System leaders identify friction points and look for opportunities to automate, streamline, or standardize the work.

Closing Thoughts

At scale, greatness isn’t shipping more features faster. It’s building a system where great features ship by default.

At scale, that's the real product:

• The system of decision-making,

• The system of customer understanding,

• The system of prioritization and execution.

Success isn’t being needed. Success is designing a system that creates clarity, flow, learning, and ownership — with or without you.

When that’s in place, you either move up to bigger, more complex systems or move on to build again.

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

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

AI is no longer a distant trend — it’s a strategic priority.

According to McKinsey report from 2023, AI adoption has the potential to generate up to $4.4 trillion in global economic value annually.

Adoption is accelerating rapidly - from the explosion of AI-generated content following ChatGPT’s release, to companies reporting tangible productivity gains, and even the rise of new roles like AI consultants.

Most leaders already recognize the potential. The challenge isn’t awareness — it’s direction.

What next? Where do you begin? How do you integrate AI safely, responsibly, and in a way that drives measurable business value?

Many teams today fall into one of two common pitfalls:

1. “We’ll wait until the technology matures.”
   The reality? AI is already mature enough to create value.

2. “Let’s find a way to add AI to our product.”
   Without a well-defined problem to solve, adding AI for the sake of AI is often a waste of time and damaged credibility.

Key Trends To Watch

The AI landscape is evolving fast. The number of new tools emerging each month is already impossible to track.

But beneath the noise, a few key trends stand out.

1. Generative AI

Generative AI tools (like ChatGPT, Claude, and Gemini) are helping teams generate content - product management documents, UX designs, software code, test cases, etc. What’s more, these large language models can be connected to your internal knowledge bases, enabling them to generate domain-specific, accurate outputs based on your proprietary data.

2. AI Agents

Instead of just responding with information, AI agents can now perform tasks on your behalf — often across multiple steps.

For example, an AI agent can read an email, check someone’s calendar, schedule a meeting, send a confirmation — all automatically.

They can also automate internal workflows like collecting customer feedback, summarizing support tickets, or triggering actions in your tools.

Think of them as a digital team member who is getting smarter and more capable every day.

3. Low-Code And No-Code AI Platforms

Platforms like Relevance AI, Bubble, and others are enabling non-technical teams to quickly prototype and deploy AI-powered solutions — without relying heavily on engineering.

This is especially valuable for startups or teams testing a new idea, where speed matters and resources are limited. These tools allow teams to test ideas, validate use cases, and iterate fast — before investing in fully engineered implementations.

By significantly lowering the barrier to entry, they empower product, operations, and business teams to explore AI opportunities hands-on, without waiting on dedicated dev time.

How Can AI Help Your Organisation

So what does that mean for your organization? Two major opportunities:

1. Enhance the Flows You Already Have

AI can be a huge productivity boost. Without innovating something new, it can boost the productivity of the workflows you already have.

Think about use cases like: Designing UX prototypes, drafting product requirements, conducting in-depth research, writing and reviewing code, automating QA, analyzing user feedback and product usage, triaging internal tickets, summarizing meetings, accelerating marketing workflows, etc.

The list keeps growing — and the impact is clear: your teams get more done, in less time, with higher consistency.

2. Improve Your Product Experience

AI can also enhance your product’s core functionality — making it smarter, faster, and more intuitive for your users.

Consider features like:

• An onboarding assistant that adapts in real time to user behavior

• Automated insights generated from reports or dashboards

• Conversational interfaces that go beyond traditional chatbots

These capabilities can directly improve your customer experience — and help your product stand out in an increasingly competitive market.

But here’s the reality:

The bar for differentiation is rising.

The technical barriers to building AI-powered features are now lower than ever. Which means if you're not evolving your product, there’s a good chance your competitors are — or soon will be.

How to Start Implementing AI Across Your Organization

The AI is starting to reshape how companies operate, build, and compete.

For many organizations, the challenge isn't whether to engage with AI, but how to do it responsibly, strategically, and without chaos.

Here’s a pragmatic, phased approach to help you get started.

1. Build Internal Awareness and Literacy Early

Start by building a shared, realistic understanding of what AI is — and what it isn’t. While many team members are likely following the latest trends, some may lack context on how AI can be applied in their work or where its current limitations lie.

Begin these conversations early — even before leadership has set formal policies.

Why?

• AI is already in use. Many teams are experimenting with tools like ChatGPT. Without guidance, this can lead to untracked, non-compliant usage.

• Bottom-up insights matter. Early engagement surfaces real use cases and concerns, helping shape more practical policies.

• It builds trust and buy-in. Starting early signals that leadership is enabling innovation, not just managing risk.

2. Set Guardrails for Safe Experimentation

Experimentation needs to be fast — but also safe.

To encourage AI exploration without creating unnecessary risk, you need some smart boundaries.

One practice is to separate lightweight experimentation from full-scale adoption.

For early testing, allow teams to explore tools under clear conditions, e.g. no sensitive data, no production integrations, and only using free or personal accounts. Ask teams to document what they’re testing and what they hope to learn. This enables quick experimentation without waiting for lengthy approvals.

If a tool shows real potential, it can then move into a more formal review process — including security, privacy, and legal assessments, as well as evaluation of vendor reliability and integration needs.

3. Identify a Cross-Functional AI Team

AI cuts across product, design, data, legal, and operations.

That’s why your early AI efforts are best led by a cross-functional team with the mandate to explore opportunities from multiple angles.

Their role is to identify where AI could create real value, run lightweight and low-risk experiments, and validate feasibility before making larger investments. Think of this group as a small, agile strike team — focused on learning, not perfection.

With the right guardrails in place, they can move quickly, helping the organization build momentum while staying aligned with broader strategic goals.

4. Encourage Teams to Explore Use Cases — With Strategic Focus

Once there’s a shared understanding of AI and basic guardrails are in place, you can encourage teams across the business to start identifying opportunities in their own domains.

One simple way to guide this exploration is by asking two key questions:

• How can AI help us increase productivity in our daily work?

• How might AI improve our product or user experience?

Encourage teams to evaluate their ideas through a strategic lens — considering feasibility, potential business value, risk, and how well each idea aligns with the company’s overall goals.

The most promising initiatives should then flow into existing planning and prioritization cycles. This ensures that AI experimentation evolves beyond isolated pilots and becomes a focused driver of meaningful business outcomes.

5. Start Small — and Start Internally

Your first AI success doesn’t need to be customer-facing.

In fact, internal use cases are often the most practical and effective starting point. They carry less risk, are easier to control, and can demonstrate clear value quickly.

Focus on areas where tasks are repetitive, time-consuming, or a known source of frustration.

Prioritize use cases that are easy to measure and quick to test — such as automating internal reporting, summarizing meetings, drafting responses to support tickets, or improving access to internal knowledge.

These behind-the-scenes wins can build momentum, reduce resistance, and create the confidence needed to take on more ambitious AI initiatives.

6. Put Coordination Structures in Place

As AI experimentation gains traction, it’s important to evolve from isolated testing to coordinated implementation. Without structure, you risk tool complexity, duplicated efforts, and compliance issues.

You can consider introducing lightweight coordination mechanisms that maintain flexibility while ensuring alignment. For example, a central inventory to track the tools, use cases, and pilots happening across the organization. Establishing and maintaining clear usage guidelines that define how AI should be applied is also essential.

With the right structures in place, you can keep innovation moving — without compromising visibility, control, or alignment.

7. Measure What Matters: Business Impact

As pilots begin to deliver results, it’s critical to focus on what truly counts: measurable business outcomes.

Focus on measuring tangible outcomes: time saved by internal teams, cost reductions, process efficiencies, improved user experiences, or faster, better-informed decision-making.

These are the results that resonate with executive stakeholders, validate the value of your AI initiatives, and build the momentum needed to expand and scale across the organization.

Your Next Step

AI is a present opportunity.

The key is to move thoughtfully, but not slowly. If you combine curiosity with structure, you will be best positioned to leverage AI’s potential — and stay ahead in the next wave of innovation.

What’s your organization’s first step? If you’re exploring AI — or unsure where to start — I’d love to hear how you’re approaching it.

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

In usability testing, numbers don’t lie—but misinterpreting them can lead to costly mistakes. Imagine launching a major redesign based on test results, only to realize later that your conclusions were skewed.

One critical factor that’s often misunderstood or overlooked? Margin of Error—the key to knowing how much you can truly trust your usability insights.

In this article, we’ll break down:

🔹 Why no usability testing results is 100% accurate?
🔹 What is Margin of Error (and why it matters)?
🔹 How to balance precision and cost in usability testing?
🔹 Practical steps to get the most accurate usability insights

Your Data Is Never 100% Accurate

Let’s say you’re in the vehicle leasing business and want to find out what percentage of Amsterdam residents have leased a car in the past two years.

Will you survey every single resident in the city?

No. You’ll take a sample—a smaller, random group representing the whole population.

And because you're only working with a portion of the population, your results can never be 100% accurate. They’re always an estimate of the true value, with some degree of uncertainty—known as the Margin of Error. A margin of error tells you how much your data could be off.

Key Statistical Concepts in Usability Testing

To make sense of your usability test results, you need to understand three key statistical concepts: Confidence Level, Margin of Error, and Confidence Interval.

1. Confidence Level

The confidence level is a value you select that reflects your tolerance for uncertainty.

• A higher confidence level means you want to be more certain, so you’re less willing to risk being wrong.

• A lower confidence level means that precision is less critical, and some uncertainty is acceptable.

There a few standard confidence levels used:

• 95%: This is the most common choice in usability testing and research. It balances certainty and practicality.

• 99%: Used in high-stakes situations where errors could have serious consequences. An example is testing the effectiveness of a new drug in medical research.

• 90%: Used for exploratory or early-stage testing, where early insights are more important than precision.

2. Margin of Error

The margin of error is a percentage that shows how much your sample results might differ from the true value.

Unlike the confidence level (which you choose), the margin of error is derived from your data and depends on factors like the sample size, variability in the data, and your chosen confidence level.

• A smaller margin of error means your results are more precise.

• A larger margin of error means your results are less precise.

For example, if the result of your testing is 60% (let’s say 60% of the surveyed participants have answered ‘Yes’), with a margin of error of 3%, it means the true value is likely within ±3% of your result (between 57% and 63%).

3. Confidence interval

Once you have the margin of error, you can easily calculate the confidence interval—the range within which the true value is expected to fall.

The confidence interval is expressed as:

[X-margin of error - X+margin of error].

In the example above, if result is 60% with a margin of error of 3%, the confidence interval would be [57% - 63%]

4. Putting It All Together

Let’s see how confidence level, margin of error, and confidence interval work together in real scenarios.

Example 1: Vehicle Leasing Survey

• Chosen Confidence Level: 90%

• Survey Result: 60% of participants reported leasing a vehicle.

• Calculated Margin of Error: ±3%

• Calculated Confidence Interval: [57%, 63%]

How to Interpret This:
With 90% confidence, we can say the true percentage of people in the overall population who leased a vehicle is between 57% and 63%.

This means that if we repeated the survey 100 times, the results would fall within this range 90 times out of 100.

Example 2: Usability Testing—Task Completion

• Chosen Confidence Level: 95%

• Testing Result: 80% of participants successfully completed the given task.

• Calculated Margin of Error: ±2%

• Calculated Confidence Interval: [78% - 82%]

How to Interpret This:
With 95% confidence, we can say the true percentage of users who would successfully complete the task is between 78% and 82%.

This means that if we conducted the usability test 100 times, the true result would fall within the range [78% - 82%] 95 times out of 100.

Factors That Influence Margin of Error

Let’s dive into the components of the margin of error formula to understand what drives it and how it behaves in different scenarios.

The error margin is a function of three parameters:

• Z (Z-Score):. This is fixed number calculated directly from the selected confidence level. For the most commonly used confidence level, we have

  • At a 95% confidence level, Z=1.96.

  • At a 90% confidence level, Z=1.65.

  • At a 99% confidence level, Z=2.58.

• n (Sample Size). This is the number of participants in your usability test or survey.

• p (Sample Proportion): The percentage or fraction of people in the test who meet the specific condition or answer the researched question positively.

  • Example: If you're testing a feature with 100 users and your goal is to observe how many will complete a certain task, and 60 of them successfully complete it, the sample proportion is 60% (p = 0.6).

Now with the formula in mind, this is what influences the margin of error.

📌 Higher Confidence Level increases the Margin of Error

If you choose a higher confidence level (e.g., 99%), the margin of error increases.

For example, if your result is 60%, and at a 95% confidence level, the margin of error is ±2%. This means you can be 95% confident that the true value falls within the range [58%, 62%].

However, if you want to express the same result with 99% confidence, you’ll need a wider range to account for the additional certainty. This results in a higher margin of error, meaning the range might expand to something like [57%, 63%] to include the true value with greater confidence.

📌 Higher Sample Size means lower Margin of Error

A larger sample size reduces the margin of error because it provides a more accurate representation of the target population. With more participants, the results are closer to what you’d get if the entire population were tested.

On the other hand, a very small sample size increases the margin of error, making the results less reliable.

📌The Variability of the Result Affects Margin of Error

The variability in your results, represented by the sample proportion (p), directly influences the margin of error. The value p*(1−p) is highest when p is around 50% and decreases as p moves closer to 0% or 100%.

For example, if 50% of users complete a task successfully, there is an equal chance of success or failure, leading to higher variability and a larger margin of error. However, if the result is more extreme—say, 90% or 10%—the outcome is more predictable, reducing the margin of error.

How to Improve Your Usability Testing Accuracy?

How can you achieve high precision in your results and reduce the margin of error?

While some factors are outside your control, like the confidence level (determined by the context of your work) or the variability in your data (the sample proportion p), there are two key steps you can take to improve your results:

1. Eliminate Biased Data

The margin of error formula assumes your data is unbiased.

What does that mean?

If you want to find out what percentage of Amsterdam residents have leased a car, it’s a bad idea to only survey people working at a car leasing company.

Why? The data would be biased, as this group is much more likely to lease cars than the general population.

Select your sample randomly so that every individual in the population has an equal chance of being included. Make sure your sample isn’t skewed toward a specific group that doesn’t accurately represent the entire population.

Without a representative sample, even a large sample size or high confidence level won’t give reliable results.

2. Adjust the Sample Size

The second important factor is the sample size.

A larger sample size reduces the margin of error and narrows the confidence interval, making your results more reliable.

Let’s say you’re working with a population of 10,000 users, a confidence level of 95%, and a sample proportion of 80%. Here’s how the margin of error decreases as you increase the sample size:

But there’s a trade-off: larger samples require more resources, time, and cost.

Testing the entire population would provide perfectly accurate results, but it’s unrealistic and unnecessary.

Balance resources and accuracy.

There isn’t a one-size-fits-all answer, but here are some tips to guide you:

• For exploratory research or initial usability tests, aim for a margin of error around 7-10%.

• For key decisions like product launches or user satisfaction surveys, aim for a margin of error between 2-5%.

• For high-stakes research, where precision is critical (e.g., medical testing or compliance studies), aim for a margin of error of 1-2%.

Practical Tips for Usability Testing

When conducting usability testing, these practical tips can help you maximize reliability and make the most of your resources:

Use a Sample Size Calculator: Many online tools are available to help you calculate the margin of error and determine the ideal sample size for your study. Here is an example of such tool. Use these calculators to experiment with different confidence levels, sample sizes, and error margins to understand how they impact your results.

Report with Transparency: Always include error margins and confidence intervals in your reports. Providing stakeholders with this information ensures they understand the reliability and limitations of the results, avoiding overconfidence in findings.

Prioritize Key Metrics: If resources are limited, focus on the most critical metrics only and ensure they are supported by adequate sample sizes.

Leverage Iterative Testing: Start with smaller, exploratory tests, identify major issues, then scale up with larger tests to refine your findings. Iterative testing saves time and resources while helping you address the most significant problems early.

Key Take Aways

If your usability tests ignore the margin of error, it's time to rethink your testing strategy.

You don’t need to be a statistician, but understanding a few principles you will significantly improve your outcomes:

📌 Use a representative sample—Ensure it's unbiased and large enough for reliable results.

📌 Confidence comes at a cost—A higher confidence level increases the margin of error, meaning you’ll need more data for precision.

📌 Balance accuracy with resources—Prioritize key metrics ensuring their accuracy.

📌 Report transparently—Always include margin of error and confidence intervals to avoid misleading conclusions.

A version of this article was originally published at https://www.logrocket.com/ on Feb 18 2025.

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

Subscribe now

Try a simple experiment. Ask your team a simple question:

“Do you feel your unique strengths and skills are fully utilized in your current role?”

Then, ask yourself the same thing.

What you’ll uncover may surprise you: hidden potential, untapped strengths, or perhaps even some frustration from talents not being fully utilized.

Natural Talent vs. Forced Growth

From a young age, we naturally gravitate toward what we excel at.

A child instinctively chooses the toys or games they enjoy—the ones they’re good at. They immerse themselves, improve effortlessly, and get better every day. Their motivation doesn’t come from pressure; it comes from the joy of mastering something they love.

But what happens when a talented child is forced into an “all-round” framework?

The result is a child who feels frustrated, disengaged, and bored—while their true potential remains hidden.

The same often happens in the workplace.

Have you ever had a performance review where the conversation focused on "fixing" weaknesses, while your real potential wasn’t even acknowledged?

How did that feel? Draining, demotivating, confidence-crushing?

What Research Says About High-Performing Companies?

When it comes to building high-performing teams, research highlights the importance of leveraging individual strengths.

Here's a look at what the data tells us:

Top-Performing Companies Have “Spiky” Leaders

Strength-based leadership has been studied extensively by organizations like Gallup, McKinsey or Harvard Business School. Their research shows that focusing on individual strengths drives better performance.

For example, McKinsey’s leadership research analyzed effectiveness across various organizations. The highlights:

• Average companies tend to focus on creating “well-rounded” leaders by fixing their weaknesses.

• Top-performing companies have “spiky” leaders. These are leaders who are exceptionally good at a few competencies, but average, or even below average, at other competencies. Instead of trying to make leaders good at everything, the top performing companies help their leaders double down on their unique strengths.

The Theory of Flow - When Do We Achieve Peak Performance

Flow is a another concept introduced by psychologist Mihaly Csikszentmihalyi, describing a state of peak performance of an individual. This state happens when we’re doing something we’re naturally good at, and it feels effortless.

In Csikszentmihalyi’s words,

A flow is a state in which people are so involved in an activity that nothing else seems to matter. The experience is so enjoyable that people will continue to do it even at great cost, for the sheer sake of doing it.

When employees operate in their area of strength, they enter this “flow state,” where creativity, productivity, and engagement peak. The more a person can spend time in flow, the more fulfilled and effective they become.

When employees frequently work outside of their flow state, their performance drops, they start experiencing anxiety or boredom. They disengage and eventually leave.

Practical Tips For Leaders To Build High-Performing Teams

So, what can you do starting tomorrow to improve productivity and build a stronger, more engaged team?

1. Leverage Each Person’s Talents

Understand the unique strengths of every team member—not just what they’re good at, but what drives them. Get to the heart of their passions, skills, and career goals.

You can use assessment tools like Gallup StrengthsFinder or PI Assessment to gain deeper insights, but don’t underestimate the power of a direct conversation.

It’s your job to understand your team’s strengths so that you can strategically align the right skills with the right activities.

The next time you’re forming a team for a new project, you’ll be prepared to create a strong team setup, and the results will speak for themselves.

2. Fill Each Other’s Gaps

Build a team around you that excels in areas where you're not as strong.

For example, if you’re not naturally inclined to organize team events, don’t waste time forcing yourself to get good at it unless you truly want to improve in that area. Perhaps there’s someone on the team who would gladly take on that responsibility. Find that person and delegate.

Encourage your team members to do the same. Understand where they’re burning out by handling tasks that drain their energy, and have a conversation about how they can offload those tasks to others who are more naturally suited for them.

3. Acknowledge Strengths

When conducting performance evaluations, genuinely recognize the person’s strengths and the impact they’ve made. This boosts motivation and drives results.

If someone’s strengths differ from your own, it might be harder for you to see their value. Stay open-minded and take the time to shift your perspective. You should recognize the unique contributions they bring to the team.

This doesn’t mean underperformance should be accepted. If someone consistently has low performance, it’s absolutely necessary to provide actionable feedback.

4. Focus On Outcomes, Not Weaknesses

Everyone has weaknesses. But instead of focusing on fixing them, focus on the outcomes a team member needs to deliver. If a weakness is hindering their ability to meet those outcomes, discuss how they can navigate it. If they’ve found their own way to work around it while still delivering great results, appreciate it.

For example, if a team member struggles with presentations but successfully lands a major client through their relationship-building skills, celebrate their success. Then, explore how they can continue to leverage their strengths while finding alternative ways to approach presentations—whether that means delegating the task to someone more suited for it, adapting the presentation style to fit their natural strengths, or even removing formal presentations from the process altogether.

The goal is not to mold them into a one-size-fits-all framework, but to maximize their impact in a way that aligns with their natural strengths and behaviors.

5. Inspire Growth But Don’t Force It

People grow and evolve—interests shift, behaviors change, and perspectives broaden over time.

But change can't be forced. It happens when the time is right, often initiated by life experiences that shift how they see the world.

When your behaviors, beliefs, and vision align with their values, you’ll spark a natural drive to improve. They will then take ownership of their growth.

As James Clear puts it:

“To change your behavior, you first need to change your beliefs. Once you change your identity—who you believe you are—your habits will follow.”

Focus on assigning a goal to an employee that resonates with them and where their strengths can shine. As they work towards these goals, they’ll naturally develop complementary skills, including their weaknesses, without it feeling forced. Their strengths will lead the way, while weaknesses improve in the background.

6. Let Individuals Shape Their Own Development Path

Every role is unique, and every individual brings their own strengths and working style. Whether you’re leading a lead, product manager, engineer, or any other role, it’s crucial to recognize these differences.

The best leaders understand this and adapt their expectations accordingly. For instance, when evaluating a product manager, use a product competency matrix—but remain flexible in how you apply it.

They might excel in some areas more than others, and that’s perfectly fine. If they’re exceptional at strategic thinking, leverage that strength to maximize their impact.

Allow them to take ownership of their development and decide which competencies to further develop, while keeping business priorities in focus.

If their personal goals don’t align with the team’s immediate needs, be open and transparent about it. And if they eventually decide to move on, you’ll know you’ve explored all options for growth.

The Bottom Line

Building a high-performing team is about maximizing the potential of each individual in a way that aligns with business goals.

When you empower your team to focus on what they do best, you not only improve productivity but also create a team of engaged, fulfilled, and happy individuals.

🌟 Are you leveraging the full potential of each team member?
🤝 Are you focusing on creating a well-rounded team of exceptional individuals whose strengths complement each other?
📈 What’s one step you will take today to help your team work in their flow and maximize their strengths?

Curious about building and scaling a high-performing product organization? Subscribe and let’s learn!"

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.

Leaders are driven to hit ambitious goals, scale businesses, and deliver results. But in the pursuit to achieve these outcomes, one critical aspect often gets overlooked: the growth and development of the people driving the progress.

Without clarity in roles, responsibilities, and expectations, questions start to arise:

• How can I grow and advance here?

• Am I meeting expectations?

• What does success in this role look like?

When answers on these questions are vague, confusion sets in—leading to misalignment, inefficiencies in hiring, or disappointment during performance evaluations.

A competency matrix is a simple and practical solution. It helps align expectations, improve communication, and support both individual and team growth.

What Is a Competency Matrix

A competency matrix is a tool that maps the skills, knowledge, and behaviors required across roles within a job family. It provides a clear structure for hiring, performance evaluations, and career progression.

For example, a product management competency matrix might outline the progression from an Associate Product Manager to Chief Product Officer. It defines not only the skills needed at each level but also the broader competencies like strategy, leadership, and stakeholder management.

Why You Need a Competency Matrix

A competency matrix brings a few key benefits: Fair Evaluations, Spotting Skill Gaps and Improved Hiring.

Especially for product teams, where roles often differ between organizations, this framework can make a big difference. It aligns expectations and ensures everyone—from leaders to new hires—knows what success looks like.

How to Create a PM Competency Matrix

Here's how to create a competency matrix.

1. Identify Job Families and Seniority Levels

If you are building a competency matrix for your team, first start by defining the job families in your team. What job families do you identify? What are the progression levels for each of them?

Here are some examples of job families and their seniority levels:

• Product Management — Associate PM → PM → Senior PM → Director of product → CPO

• Product design — Junior Designer → Designer, Senior designer, Director of Design

• Engineering: Junior Engineer → Engineer → Senior Engineer → Engineering Manager → CTO

A competency matrix refers to a specific job family.

2. Define Core Competencies

Now let’s get into the heart of building a competency matrix: defining the core competencies for the product management (PM) family.

What makes a competency?
A competency is more than just a skill—it’s a combination of knowledge, skills, abilities, and behaviors required to perform a role effectively. While skills are often technical or task-specific, competencies focus on how those skills are applied in real business contexts.

For example:

• Skill: Using a roadmapping tool.

• Competency: Product strategy and roadmapping—combining tools, vision, and decision-making to deliver a meaningful product plan.

Approach This Thoughtfully.

Creating a list of competencies isn’t something to rush. It should reflect your organization’s values and expectations for success at every level.

• Collaborate with Stakeholders: Engage with team leads, peers, and leadership to align on what matters most. Competencies should reflect not just the role but also the culture and goals of the organization.

  • What does our organization value?

  • What do you expect from PMs at each level?

  • What baseline skills, behaviors, and mindsets are essential for success?

• Keep It Flexible: Allow room for flexibility and iteration as your team evolves. If you review it in a few weeks, you’ll likely spot points to improve.

Here’s an example of eight competencies for the product management job family, classified in four categories: Strategy, People, Process, and Pproduct:

Note that some competencies, like product strategy and roadmapping, are unique to the product management job family. Others, such as leadership and stakeholder management, are more universal and apply across multiple job families, including both product management and engineering.

3. Build the Competency Matrix

If you're confident in the chosen competencies, it's time to build the competency matrix. This involves mapping out the responsibilities and proficiency levels required for each competency across different seniority levels.

Here’s a glimpse of what it could look like:

For the full Product Management Competency Matrix, including a downloadable Excel version, scroll to the end of this post.

How to Use a Competency Matrix

Now that you’ve built your competency matrix, it’s time to turn it into a practical tool that drives growth, alignment, and better decision-making. Here’s how to put it to work effectively:

1. Personal Evaluations

Most organizations already have a process for performance evaluation and development. Integrate the competency matrix in the existing process to make it more actionable.

• Map Individual Progress: Assess where each team member stands within the matrix.

  • Are there gaps holding them back from achieving their goals?

  • Do these areas of improvement align with their aspirations?

• Bring It to 1:1s: Use the matrix as a foundation for open discussions. Instead of vague feedback, you’ll have a structured framework to:

  • Highlight strengths.

  • Address areas for improvement.

  • Agree on next steps for growth.

• Buy-In Is Key: Without the team’s agreement and engagement, the matrix risks becoming a checkbox exercise. Focus on collaboration, not just evaluation. When the process feels fair and actionable, it becomes a tool for empowerment rather than judgment.

2. Identifying Team Gaps

The matrix isn’t just for individuals—it’s a powerful tool to identify gaps at the team level.

Use these insights to address gaps. Consider targeted training, mentoring, or hiring for new roles.

• Map the Team: Assess the current skills and competencies of your team against the matrix:

  • Are there key skills missing in the team in critical areas?

  • Are there gaps that could limit your ability to scale?

• Define Actions: Use these insights to address gaps.

  • Invest in targeted training or mentorship programs.

  • Use the matrix to identify roles that could fill these gaps.

3. Improve Your Hiring Process

Try using your competency matrix in the hiring process. It will bring clarity and structure at every stage.

• Before the Interview: Use the matrix to define exactly what you’re looking for in a candidate. This keeps the process focused on what truly matters for the role.

• During the Interview: Use the matrix as a live guide to evaluate candidates:

  • Map their skills, behaviors, and experience against the required competencies.

  • Ask questions to assess how well they meet key expectations.

  • When candidates ask, “How can I grow in this role?” use the matrix to outline a clear growth path.

• After the Interview: Use the matrix to align stakeholders on the candidate’s suitability. A shared framework reduces bias and ensures consistency.

How a Competency Matrix Helped Us Hire

When I introduced a new role to address a critical gap on my team, it quickly turned out to be more challenging than expected.

The role was highly collaborative, requiring coordination across multiple teams within the organization. Naturally, stakeholders from various departments were eager to provide their input in the hiring process, which added layers of complexity.

Finding the right candidate was difficult, but a deeper issue surfaced: a lack of clarity and alignment.

• Each stakeholder had a different interpretation of the role’s responsibilities.

• Finding a candidate who met everyone’s expectations was nearly impossible.

• The misalignment was slowing the process down for everyone involved.

We introduced a competency matrix. It pushed us to revisit and refine the role’s requirements, clarify the key competencies, and formalize the position’s growth potential. The matrix became the foundation for a more aligned, efficient, and effective hiring process.

Here’s what changed:

• Improved clarity: Everyone gained a clear understanding of the role’s expectations, purpose, and growth path.

• Structured interviews: Discussions with candidates became more focused, consistent, and aligned with key competencies.

• Aligned evaluations: Stakeholders assessed candidates using the same criteria, leading to better and faster decision-making.

Practical tips: Make your Competency Matrix a Living Tool

When used the right way, a competency matrix can be a powerful asset. But if it’s treated as a “check-the-box” exercise, its value quickly fades.

Keep it relevant, actionable, and impactful with these practical tips:

Use It as a Guide, Not a Box

The matrix is a tool—not a rigid rulebook. Respect individual talents and unique profiles.

Exceptional candidates and team members often don’t check all boxes but they have exceptional unique skills that can bring immense value.

Use the matrix to guide decisions, not to limit them.

Keep It Fresh: Regular Updates

Teams evolve, companies grow, and priorities shift. To stay relevant, revisit the matrix periodically. Every iteration is an opportunity to improve.

When to review it?

• When new roles are introduced.

• When teams expand.

• When the business or strategy changes.

Involve Teams for Alignment

Engage relevant stakeholders to ensure alignment, especially for competencies that overlap across job families or teams (e.g., leadership or stakeholder management). While expectations for roles differ, basic ground rules should apply across the organization.

For example:

Leading a team of engineers should compare reasonably to leading a team of designers or analysts. While the specifics may differ, the core expectations should align.

Stay Aware of Industry Trends

Every company is unique, but benchmarking against industry practices keeps your matrix grounded.

• Is your “Director of Product” role in line with similar companies at your scale?

• Are you using language that resonates with both internal and external audiences?

Follow the trends to make the role understandable and appealing for both internal and external hires.

Share the Matrix

Make the matrix accessible to your team so they know what’s expected from them and how they can grow.

Sharing it also opens the door to valuable feedback, allowing you to refine and ensure it remains relevant.

Use Tools That Work For You

The matrix is quite simple, so there’s no need to use any advanced tooling.

Excel, Google Sheets, Miro, or Confluence, anything works perfectly well.

Choose what’s already accepted and familiar in your organization. Most important is to ensure adoption of the tool.

To Wrap Up

A structured approach to people development demonstrates maturity and professionalism.

If you’ve relied on gut feeling only when hiring or promoting, introducing a competency matrix can make a difference. It brings clarity for you, clarity for your team, and clarity for new hires.

That said, remember: the matrix is a guide, not a rulebook.

Exceptional people don’t fit into predefined boxes — their strengths and weaknesses are unique. This is what sets them apart.

Keep room for flexibility and let your talent shine.

Originally published at https://blog.logrocket.com/ on December 27, 2024.

📥 Download the Full Product Management Competency Matrix in Excel Format
This detailed matrix includes all the core competencies, progression levels, responsibilities and actionable examples (Available for paid subscribers).

Read more