Ideation & Discovery

If you are a founder or product leader at an early or growth-stage company, you probably know this moment. You have an idea, or a mandate to build something new. You have a deck, some conversations with customers, maybe a few investors asking pointed questions. What you do not have is a senior product and engineering team to tell you, honestly, whether this is the right thing to build, and what the first version should be.

That gap is expensive. Inside every product idea sit dozens of decisions: who it is really for, how painful the problem is, what customers use today, how big the market really is, why anyone would switch, what to build first and what to leave out. Without a structured way to answer them, each decision quietly becomes an assumption, and the assumptions become a roadmap your runway now depends on.

The risk is growing, not shrinking. AI has made software dramatically faster to build. A small team can now ship in weeks what used to take months. That is a real advantage, but it also means it has never been easier to build the wrong product quickly, and to burn a funding round doing it.

Product Ideation & Discovery is how we close that gap. In three to ten working days, a senior Supernova team runs your idea through the same structured framework that experienced product companies use, and hands you a clear, evidence-backed answer on what to build, who it is for, and whether to build it at all.

Three ways to start a product

Most new products begin in one of three ways. From the outside they can look similar. Underneath, they lead to very different outcomes.

Build first, learn later

The fastest-looking path is to start building straight away. A founder has a strong instinct, a customer asks for a feature, or a competitor launches something, and the team gets to work.

Sometimes this works. More often, the team spends months building something, launches it, and only then discovers that the customer was the wrong one, the problem was not painful enough, or nobody was willing to pay. By then the money is spent and the code has to be rewritten or thrown away. Speed was never the problem. The direction was.

Research until it feels safe

The opposite path is the traditional consulting project: weeks or months of workshops, interviews and reports before anything is decided.

This feels careful, but it carries its own cost. Markets move, budgets run down, and the team ends up with a thick folder of findings and no clear answer. Research that does not end in a decision is just a slower way of guessing.

Learn quickly, then build with confidence

We chose a third path. We do the hard thinking up front, but we do it in days, not months, and we always end with one clear recommendation.

This is harder to do well than either of the other two. It means talking to real customers rather than relying on opinions. It means being willing to tell you that your original idea needs to change. And it means running customer research, market analysis, product thinking and technical planning side by side, instead of one after another.

We think it is worth it. A few days spent finding out that the customer is wrong or the market is too small can save months of engineering. And when the evidence is strong, those same few days remove the hesitation, so your team can stop debating and start building.

Is this for you?

Discovery is built for one situation: "We believe there is an opportunity, but we do not yet have enough evidence to confidently commit to building."

You are likely a good fit if you are:

• A founder or CEO, pre-seed to Series B, with an idea or early product, about to commit serious money and months to building it

• A CPO or product leader weighing a new product line or a major change of direction, and needing evidence your board will accept

• An established business launching its first software product, or replacing a manual process with software

• A team whose first version has not taken off, and who wants to understand why before spending more to rebuild it

• Without a senior product and engineering team in-house, or not ready to hire one before you know what you are building

It also helps if you are preparing to raise. Investors will ask who your customer is, how big the market really is, why customers will switch, and what the first version needs to prove. Discovery gives you evidence-backed answers to every one of those questions.

Discovery is not the right fit if you already know exactly what needs building and simply want it built. That is a design or engineering engagement, and we can help with that separately. We also do not offer hourly developers, bug fixing, maintenance, brochure websites or small feature additions. And discovery only works if you are open to what the evidence says, including when it disagrees with you.

The six-stage framework

Every discovery we run follows the same six stages: Frame → Discover → Validate → Define → De-Risk → Decide. Each stage answers one question, uses a small set of proven methods, produces named outputs, and ends with an exit gate: a check we must pass before moving on. If we cannot pass it, we do not continue.

We deliberately limit ourselves to the methods that earn their place. Each one below is explained in plain terms in the stage where we use it.

The same framework sits behind all three of our discovery packages. A smaller engagement moves through each stage faster; a larger one goes deeper. No package skips a stage.

Stage 1 — Frame

What exactly do we need to learn before we can recommend building this?

You come in with a vision. Some of it is fact, but most of it is belief that feels like fact: who the customer is, what they will pay, how you will reach them. Framing turns your idea into a clear list of what must be proven, so nothing important is left to chance.

We start with a kickoff session covering why this product, why now, who you believe needs it, what problem you believe exists, what evidence supports that, what happens today, what would make the business valuable, and what could make it fail. We also collect everything you already have: your vision, business goals, pricing ideas, existing research and analytics, current users, known competitors, technical and regulatory constraints, target markets, timeline and budget.

The methods we use

• Assumption Mapping. We write down every belief your business depends on and sort them into eight categories: customer, problem, demand, market, product, growth, technology and business. Founders are often surprised how many of their plans rest on beliefs nobody has tested.

• Impact × Uncertainty prioritisation. Each belief is scored on two things: how badly it would hurt if it were wrong, and how unsure we are about it today. The ones that score high on both, the beliefs that could sink the business and that nobody has checked, are tested first.

What you get

• Discovery Brief: a short document that sets out what we are investigating and why.

• Product Vision: your idea captured in one clear statement everyone can align on.

• Assumption Register: every belief your business depends on, ranked by risk.

• Research Plan: exactly how each high-risk belief will be tested.

Why it matters to you: most failed products did not fail because of bad engineering. They failed because a critical assumption was never tested. Framing makes those assumptions visible on day one, while they are still cheap to deal with.

Exit gate: can the team clearly explain what must be proven, disproven or better understood? If not, we do not continue.

Stage 2 — Discover

Who feels this problem most strongly, and what are they doing about it today?

This is where we go to the people who live with the problem. The aim is not to ask what features they want. It is to understand what they are trying to get done, and whether they care enough to change how they do it today.

The methods we use

• Jobs-to-be-Done (JTBD). Customers do not buy products; they "hire" them to get a job done. We map the situation the customer is in, what triggers the need, what motivates them, the outcome they want, what they do today, and the workaround they rely on. The question is never "what features do users want?" but "what are they trying to get done?"

• The Mom Test. A proven interviewing method, named because even your mum would lie to you about whether your idea is good. We never ask "would you use this?", "would you pay for this?" or "do you like this idea?" People are polite and say yes. Instead we ask about real past behaviour: tell me about the last time this happened. What did you do? What did it cost? How often does it happen? What have you already tried? Who decides what gets bought? What made you last switch tools?

• Evidence grading. Every finding is rated by strength. Opinions, compliments and "I'd probably use it" are weak. Repeated frustration and people actively searching for alternatives are moderate. Money already being spent, an existing workaround, usage data or a signed commitment are strong. The rule: past behaviour beats future promises, real spend beats stated willingness to pay, and an existing workaround beats a compliment.

• Ideal Customer Profile (ICP) and early-adopter segment. We define exactly who to build for first. Not "small businesses", but "independent salons with three to ten staff, handling more than a hundred bookings a month and rescheduling clients by hand over WhatsApp." We capture their context, behaviour, how often the problem hits, how painful it is, what triggers a purchase, and who holds the budget. For B2B products, we separate the user, the internal champion, the decision-maker and the buyer, because they are often four different people.

What you get

• Ideal Customer Profile: exactly who your product is for.

• Early-Adopter Segment: the group most likely to buy first, and where to find them.

• Jobs-to-be-Done map: what your customers are really trying to achieve.

• Customer Evidence Summary: what customers told us and showed us, graded by strength.

• Validated Problem Statement: the problem, proven with evidence rather than assumed.

• Current Alternatives: what customers use today instead of you.

Why it matters to you: a precise customer is the difference between marketing that converts and money spent shouting into the void. And interview evidence graded honestly is exactly what investors probe for when they ask "how do you know?"

Exit gate: we must be able to answer who has the problem, how often and how painfully, what they do now, why they might change, and what evidence supports all of it.

Stage 3 — Validate

Is this opportunity commercially worth pursuing?

A real problem does not automatically mean a good business. This stage tests whether there is enough money within reach to justify the investment.

The methods we use

• TAM / SAM / SOM market sizing. The three numbers every serious investor asks for.

  • TAM, Total Addressable Market: the biggest possible market, if every relevant customer bought. It shows the long-term ceiling of the category.

  • SAM, Serviceable Available Market: the part of that market your product can actually serve, once you account for geography, target segment, regulation, product capability, pricing, technology and distribution.

  • SOM, Serviceable Obtainable Market: what you could realistically capture in the next one to three years, given your sales capacity, capital, channels, competition, pricing, product readiness, team and ability to execute. This is the number that matters most, and it is a realistic figure, not an aspirational one.

• Bottom-up sizing. We build your SOM from the ground up: reachable customers multiplied by realistic annual value per customer. Top-down figures from industry reports are used only as background. We never build your business case on a giant global market report.

• Competitive & Alternative Analysis. We map four kinds of competition: direct competitors, indirect competitors, manual alternatives (spreadsheets, WhatsApp, email, paper, staff), and doing nothing, which is often the most important competitor of all. For each, we look at who it serves, its positioning, value proposition, pricing, workflow, strengths, weaknesses, customer complaints, distribution, switching cost, and the gap it leaves open.

• Demand & pricing validation. We look at current spend, existing budgets, purchase triggers, urgency, switching behaviour, price sensitivity, what the problem costs customers today, and signs of willingness to pay. The result is a Pricing Hypothesis: a starting price to test, not a final price.

What you get

• TAM, SAM and SOM: a credible, defensible view of the market at all three levels.

• Market Opportunity Assessment: whether the opportunity is big enough for the business you want to build.

• Competitive Landscape and Alternative Landscape: who and what you are really up against, and where the gap is.

• Demand Evidence: proof that customers will act, not just agree.

• Pricing Hypothesis: a starting price point, and the evidence behind it.

• Commercial Viability Assessment: a clear view of whether this can make money.

Why it matters to you: a market size investors can poke holes in will hurt your raise. A bottom-up SOM, with a clear view of the competition including "doing nothing", is a number you can stand behind in any room.

Exit gate: is there enough reachable economic value here to justify further investment?

Stage 4 — Define

What should we actually build?

Only now, with the customer, problem and market understood, do we design the product. We leave it until stage four on purpose: the evidence should decide the product, not the original feature list. This stage produces five things: the product opportunity, the product direction, the MVP, the growth strategy and the defensibility strategy.

The methods we use

• Opportunity Solution Tree. A simple map that works backwards: Desired Outcome → Customer Problems and Needs → Opportunities → Possible Solutions. It stops teams jumping straight to features and makes every product decision traceable back to a real customer problem.

• Solution ideation. We generate at least three materially different directions, not three cosmetic versions of the same app. Depending on the problem, that might be software, automation, a marketplace, a workflow tool, an API, an AI agent, an integration layer, or a service-plus-software model.

• ICE scoring. Each direction is scored on Impact, Confidence and Ease. The score supports the decision; it never replaces product judgement.

• Product Hypothesis. The chosen direction is written as one testable statement: We believe [target customer] will [desired behaviour] because [problem or value]. We will know this is true when [measurable evidence] occurs.

• Value Proposition & Positioning. Who it is for, the problem it solves, the alternative it replaces, the category it sits in, the reason to switch, and what makes it different.

• MVP Blueprint. We define the smallest product capable of proving your critical product and business assumptions. That is not the same as the smallest amount of software engineering can ship. It covers the core customer, the core job, the primary user journey, essential capabilities, success criteria and, deliberately, what is excluded.

• MoSCoW prioritisation. Every capability is sorted into Must Have, Should Have, Could Have and Not Now. The "Not Now" list is mandatory. It is the single most effective protection against a bloated first version.

• Growth Strategy and First 100 Customers. Where do the first 100 customers come from, and what gets you beyond them? We do not pick ten channels. We choose one primary and one secondary acquisition route, from options such as founder-led sales, outbound, partnerships, channel partners, product-led growth, content, search, marketplaces, communities, referrals and integrations. Then we map the growth model: Acquire → Activate → Deliver Value → Retain → Refer or Expand.

• Defensibility Strategy. If this succeeds, what becomes harder to copy or replace? Proprietary data, network effects, workflow integration, switching costs, distribution, integrations, proprietary technology, brand and trust, or economies of scale. You do not need a strong moat on day one, but you should know where one could build up, how, over what time frame, and what it would take.

What you get

• Opportunity Map and Recommended Product Direction

• Product Hypothesis: the bet, written so it can be tested

• Value Proposition and Competitive Position

• Core User Journey: the main path a customer takes through the product

• MVP Blueprint and Not-Now Scope: what the first version includes, and what it deliberately does not

• Growth Strategy and First 100 Customers Strategy

• Defensibility Strategy

Why it matters to you: without a senior product team, the first version tends to become everything everyone has asked for. A clear MVP Blueprint with a firm Not-Now list protects your runway, and a credible First 100 Customers plan answers the question every investor asks after "what are you building?"

Stage 5 — De-Risk

Is there a realistic technical and operational path to building this product?

This is the stage most non-technical founders cannot do alone, and the one that most often goes wrong when skipped. Our senior engineers test whether the product can be built and run sensibly before you commit a budget to it.

The methods we use

• Technical Direction. Which platform the product should run on (web, mobile, native or cross-platform, desktop or an API), plus the five things that shape every build: the high-level architecture; the main data entities and flows; the integrations it depends on (APIs, SDKs, payment providers, identity, CRM, third-party tools, external data); the security requirements; and the compliance rules that genuinely apply, such as PCI DSS for card payments, GDPR for personal data, HIPAA for health data, SOC 2 for enterprise customers, or financial regulation. We cover scalability only where it changes the product direction.

• Modern Technology Opportunity Review. Has new technology changed the best way to solve this problem? We look at LLMs, AI agents, multimodal AI, voice, computer vision, automation, modern APIs, open-source models, serverless infrastructure, retrieval and search, real-time infrastructure and low-code internal tooling. The rule: use new technology where it creates leverage, not because it is fashionable.

• Build vs Buy. Authentication, payments, communications, search, analytics, cloud infrastructure, identity verification, AI models and storage already exist as mature services. We custom-build only where owning it creates a meaningful advantage, so your engineering budget goes where it makes you different.

• Technical Risk Review. Every technical question is classed as Known (straightforward), Risk (needs mitigation), Unknown (needs investigation) or Blocker (could invalidate the solution).

• Product Risk Register. Wider risks across customer, value, usability, market, growth, feasibility, technology, regulation, operations and viability, each with its evidence, probability, impact, mitigation, owner and status.

• Success Metrics, defined before development. One Primary Product Outcome, the single metric that shows whether the product delivers real customer value, supported by measures for acquisition, activation, engagement, retention, revenue and referral. The question it answers: what must the first version prove before we confidently invest more?

• Indicative Development Plan. An MVP roadmap, major dependencies, likely team structure, delivery complexity, indicative timeline, any technical spikes (short experiments to settle a technical unknown), and an indicative investment range. This is directional planning, not a fixed engineering quote, which comes after detailed design.

What you get

• Technology Strategy and High-Level Architecture

• Modern Technology Opportunity Review: where AI and newer tools genuinely help

• Build-vs-Buy Matrix and Integration Map

• Risk Register and Security / Compliance Considerations

• Success Metrics

• Indicative Development Roadmap, Team Shape and Build Estimate

Why it matters to you: without a CTO, it is very hard to know whether a quote is fair, whether a technical approach will hold up, or what you should not be paying to build. This stage gives you a senior engineering view, a realistic budget and timeline, and the technical credibility to answer investors' questions on feasibility.

Stage 6 — Decide

Should the business invest in building this product?

Everything comes together into one investment recommendation, judged in three ways.

1. The four core risks. The standard test experienced product teams use before committing to build:

• Value: will customers want it?

• Usability: can customers understand and use it?

• Feasibility: can we build and operate it?

• Viability: can this become a worthwhile business? This brings together the market sizing, pricing, economics, growth, competition, defensibility and regulatory environment.

2. Eight quality gates. No recommendation is made until the work passes all eight:

1. Customer: do we know who this is for?

2. Problem: do we have credible evidence the problem exists?

3. Demand: is there evidence customers will take action?

4. Market: are TAM, SAM and SOM attractive enough?

5. Product: is there a compelling product direction?

6. Growth: is there a credible route to customers?

7. Feasibility: can it be built sensibly?

8. Viability: can this plausibly become a viable business?

Defensibility is assessed too, but a weak moat on day one is not an automatic fail.

3. Honest evidence levels. The word "validated" gets used far too casually in startups. We use five defined levels, and every finding is labelled with one:

A discovery engagement typically takes your critical assumptions to Level 2 or 3. It does not, and cannot, prove product-market fit; only a live product with real customers can reach Level 4. We will never overclaim validation, and you should be wary of anyone who does.

The outcome is always exactly one recommendation:

• Build: the evidence supports progressing to an MVP.

• Build with conditions: the opportunity is strong enough, but specific risks must be addressed first.

• Pivot: the opportunity may be real, but something meaningful must change: the customer, problem, solution, value proposition, pricing, business model, distribution or technology.

• Walk away: current evidence does not justify further investment.

Why it matters to you: you get a decision you can take to your co-founders, your board or your investors, with the evidence and reasoning laid out, and an honest statement of how certain it is.

How we deliver all of this in days

Six stages of serious work would traditionally take a consulting firm months. We complete them in three to ten working days. Three things make that possible.

Four specialists working at the same time

A traditional project runs one step after another. Once the framing is done, our work splits into four streams that run side by side and come back together for the decision.

A fixed plan for every day

Every package follows a set day-by-day schedule, so you always know where the work stands.

We use modern tools and AI throughout to speed up research, analysis and synthesis. They make us faster. They never make the decisions; experienced people do.

Three moments you are in the room

We will not flood you with raw research. Instead, you are involved at the three points that matter:

1. Kickoff: we agree the goals and write down the beliefs to test.

2. Midpoint review: we share what we tested, what we learned, what has changed, and what is still uncertain.

3. Final decision workshop: we walk you through what we believed at the start, what the evidence showed, what changed, our recommendation, what to build and not build, and what happens next.

Nothing is handed over until it passes our internal quality check, which confirms every stage of the framework has been completed and every conclusion is backed by the evidence behind it.

What you leave with: the Product Discovery Blueprint

Discovery does not end with twenty disconnected reports or a folder of raw research. It ends with one master document, the Product Discovery Blueprint, which brings every stage together in 26 sections.

You own the Blueprint outright, along with all the research, recommendations, concepts and requirements created for your product. We keep only our own methodology, frameworks and templates. You can build with us, build with your own team, work with another company, pivot or stop. Keeping discovery independent from the build is deliberate: it is the only way our recommendation can be trusted.

Three ways to work with us

All three packages use the full six-stage framework. What changes is how deep each stage goes.

Every engagement has a fixed scope, a fixed timeline and a fixed fee, agreed in writing before we start. The proposal sets out exactly how many interviews, markets, customer groups and competitors are covered, and whether prototypes or technical trials are included. You are paying for a clear answer, not for hours of workshops.

What discovery does not include

Discovery tells you what to build. It does not build it. Production design, a full design system, production software, detailed technical specifications, legal advice, regulatory certification, branding, naming, and marketing or sales execution are separate services that come afterwards.

What we need from you

One person who makes the final decision, access to your existing research, data and technical information, any known regulatory requirements, introductions to customers wherever possible, and timely feedback. Delays on these inputs can extend the timeline.

Why we will sometimes tell you not to build

We never promise that discovery will prove your idea right. What we promise is that you will leave with a clear, evidence-backed answer on whether to build, change direction, or walk away.

That distinction matters to us. If every discovery we ran ended with "build it", it would mean we were telling clients what they wanted to hear. Sometimes the evidence says the customer is different from the one you imagined. Sometimes the product needs to change. And sometimes the most valuable thing we can do is help you walk away before months of engineering and money go into the wrong product. That is not a failed discovery. It is exactly what discovery is for.

When the evidence is strong, discovery does something just as valuable: it removes doubt. Your team stops debating what might work and starts building against a clear plan, knowing why each decision was made.

Software is becoming faster and cheaper to build every year. That makes the decisions you take before building more important, not less. Less guessing, less wasted engineering, and far more confidence in what gets built next. That is what we set out to give every client.