Product Development & PMF

Product development is where product-market fit is either discovered or quietly undermined.

Teams don’t fail to achieve product-market fit because they aren’t building enough. They fail because they build without learning, scale without evidence, or confuse motion with progress.

Product-market fit is not found through velocity alone. It is shaped through deliberate development decisions that prioritise learning, signal over noise, and clarity over output.

Product Development Is a Learning System

Effective product development is not about shipping features. It is about reducing uncertainty.

Every meaningful development decision should answer one of three questions:

  • Are we solving a real problem?
  • Is the solution creating genuine value?
  • Are customers demonstrating demand through behaviour, not opinion?

When development becomes detached from these questions, teams can move quickly and still move in the wrong direction.

Iteration Without Learning Is a Warning Sign

Iteration is often treated as progress by default. It isn’t.

Healthy iteration:

  • Produces clearer signals over time
  • Narrows uncertainty
  • Sharpens focus on what matters

Unhealthy iteration:

  • Increases surface area without increasing confidence
  • Recycles the same feedback in different forms
  • Creates the illusion of momentum while direction remains unclear

Speed only helps when learning compounds. Without learning, speed accelerates waste.

MVPs Are Tests, Not Mini Products

An MVP is not:

  • A smaller version of the roadmap
  • A cheaper way to build the “real” product
  • A justification to ship something unfinished

An MVP is:

  • The smallest possible test of a real value hypothesis
  • A way to observe behaviour, not collect opinions
  • A tool for learning what customers will actually adopt

Teams often skip this step and move directly into feature accumulation. That decision alone can delay product-market fit by years.

Agile Helps Execution, Not Direction

Agile practices are valuable, but they do not replace strategic direction.

Teams can:

  • Run clean sprints
  • Ship regularly
  • Hit delivery targets

And still be fundamentally misaligned with the market.

Product-market fit decisions usually sit outside sprint rituals. They require stepping back, questioning assumptions, and resisting the pressure to keep building simply because a team is in motion.

Agile helps teams move. Strategy determines where they go.

Pivot or Double Down

Few decisions are as consequential, or as emotionally charged.

The question is rarely “should we pivot?”

The real question is “what are the signals telling us?”

Pivot when:

  • Learning is strong but adoption is weak
  • Customers engage, but not with what you expected
  • The problem is real, but the solution isn’t landing

Double down when:

  • Demand is uneven but genuine
  • Adoption improves with focus, not expansion
  • Small wins compound when friction is removed

The most dangerous situation is neither. It is continuing to build while avoiding the decision altogether. 

Development Decisions That Delay Product-Market Fit

Certain patterns show up repeatedly in teams that struggle to find fit:

  • Scaling teams before demand is proven
  • Prioritising edge cases before core value is clear
  • Confusing engagement with delivered value
  • Letting architecture decisions outrun product clarity
  • Treating customer feedback as feature requests instead of signals
  • Optimising for internal alignment over external evidence

These decisions often feel reasonable in the moment. Their cost usually becomes visible later, when momentum slows and course correction becomes expensive.

Product-Market Fit Is Not a Phase

Product-market fit is not something teams “get” and move on from.

Markets change. Customers evolve. What worked stops working.

Strong product development:

  • Continuously tests assumptions
  • Revalidates demand as context shifts
  • Protects fit as the product scales

Growth without this discipline eventually erodes the very fit that made growth possible.

How I Work With Teams on Product Development

I work with founders and leadership teams at moments where product development decisions carry outsized risk and long-term consequences.

I’m often brought in when teams are executing well but no longer confident they are executing the right things.

This usually happens when teams are building quickly, pressure is rising, and it’s no longer obvious which signals to trust.

My work often focuses on:

  • Clarifying which signals indicate real demand, and which are simply noise
  • Separating genuine learning from activity that only looks like progress
  • Pressure-testing assumptions before teams scale people, scope, or complexity
  • Helping teams decide what not to build, and when to stop
  • Reconnecting product development decisions to clear strategic intent without slowing execution

The goal is not to add process or introduce new frameworks.

The goal is to restore clarity, confidence, and shared understanding of what the team is building, who it is for, and why it matters.

Start with a product strategy discussion

Clear product decisions don’t come from more process. They come from better judgment, grounded in market reality.

Scroll to Top