Run a mock round

An MVP is the smallest thing we can build that lets us test our most important assumption with real users and learn from their behaviour.

The key word is learning, not cheap or unfinished. I start by identifying the riskiest assumption, often whether customers care enough to use it or pay for it. Then I design the minimum experience that produces a real signal about that assumption.

That might be a manual, concierge process rather than software, or a single core workflow rather than a full suite. I define in advance what success looks like and what we will do with the result.

I deliberately exclude anything that does not affect the test, even if it is nice to have. I also keep quality high on the part we do build, because a confusing MVP produces misleading data. After launch I measure, learn and decide.

I never say no flatly. I make the trade off explicit and let the decision be informed.

First I listen properly and understand the need behind the request. A senior stakeholder's pet feature often represents a real customer problem, and I reflect that back. Then I explain the cost: what would be delayed or dropped to do this, using the roadmap and capacity as evidence rather than opinion.

I bring data where it exists, such as usage, revenue impact or customer evidence, and I propose alternatives: a smaller version, a test, or a place in a later cycle.

If the stakeholder still wants to proceed, I ask them to own the trade off explicitly and I document the decision, so it is a conscious choice rather than a silent scope increase. I keep the relationship intact by being transparent, consistent and respectful, and by delivering on what we agreed.

Discovery is how we reduce risk before committing to build. I treat it as continuous, not a phase.

I start with the problem and the target customer, and I review existing data, support tickets, analytics and sales calls to understand where the pain is. Then I write down my assumptions and rank them by how uncertain and how important they are.

I test the riskiest assumptions with the cheapest method that works: customer interviews, fake door tests, prototypes, concierge experiments or data analysis. I talk to real users rather than only internal stakeholders, and I ask about behaviour and past actions, not hypotheticals.

I synthesise what I learn into an opportunity statement and a small experiment plan, then decide whether to build, iterate or stop.

The output of discovery is evidence and a decision, not a document.

Waiting for perfect data is itself a decision, usually a costly one. I aim for the best decision available with the evidence I have.

First I ask what is reversible. If the decision is cheap to undo, I decide quickly, set a clear checkpoint and move. If it is expensive or one way, I invest more in evidence.

Then I list what I know, what I do not know and what would change my mind. I size the risk and gather the cheapest useful data, a few customer calls, a quick analysis or a small test, rather than a full study.

I consult the people closest to the problem, decide, and communicate the reasoning and assumptions so the team understands why. I set a date to review the outcome.

One example: I chose to simplify onboarding based on five user interviews and funnel drop-off data, then measured the effect, which confirmed the direction.

I align people through a shared, visible goal and a clear decision making process, not through endless meetings.

I start by understanding what each group cares about. Engineering wants clarity and low churn, design wants user quality, business wants revenue and dates. I translate the same objective into their language.

I create one source of truth, a roadmap or one pager that shows the problem, the intended outcome and the priorities, and I share it widely. I define who decides what so we avoid consensus paralysis: who is consulted and who owns the final call.

I run regular, short reviews rather than big reveal meetings, so surprises are rare, and I surface trade offs openly. When there is genuine disagreement I bring it back to evidence and strategy, and if needed escalate a decision quickly rather than letting it drift. Trust comes from consistency between what we say and what we ship.

Product-market fit is the point where a product satisfies a strong market demand well enough that it grows, retains and pulls customers in without heroic effort.

I do not rely on a single metric. I look at a cluster of signals. Retention is the strongest: a cohort curve that flattens rather than falling to zero shows people keep getting value. Organic growth and word of mouth, high referral rates and unprompted demand matter. Qualitative signals include customers being upset when the product goes down, and sales cycles getting shorter.

I use frameworks such as the Sean Ellis test, asking how disappointed users would be if the product disappeared, with a benchmark around forty percent very disappointed.

I also segment carefully, because fit can exist in one niche and not another. When the signals are strong I invest in scaling. When they are weak I keep improving the core before spending on growth.

Outputs are things we produce: features, releases, documents. Outcomes are the changes in customer behaviour or business results those outputs are meant to create.

Shipping a new dashboard is an output. A measurable lift in the number of weekly active users who complete a task is an outcome. Teams that track only output can ship constantly while delivering no value.

I define outcomes as specific and measurable statements, for example reduce time to first value from ten minutes to three, or increase trial to paid conversion by five percentage points. Then I choose the outputs most likely to move them, and I measure after release.

Outcome thinking also changes how you respond to failure. If a feature ships and the metric does not move, that is useful learning, not a wasted quarter, and it informs the next bet. Output thinking tends to reward activity.

I start by reconnecting to strategy. If everything is urgent, the problem is usually that priorities have not been agreed or that every request is being treated as equal.

I use a framework such as RICE, reach, impact, confidence and effort, or a simple value versus effort matrix, to make trade offs visible and comparable rather than political. I always consider the cost of delay: what do we lose by not doing this now?

Then I check capacity. The roadmap is a bet against finite team time, so saying yes to one thing means saying no to another, and I make that explicit.

I share the criteria with stakeholders so decisions are transparent, and I review the roadmap regularly because priorities change. I protect a portion of capacity for bugs, discovery and technical health.

Most importantly I communicate why something is not on the list, not just what is.