Design
Decide what to build
before anyone writes code
Roughly half the features in a typical enterprise backlog are never used enough to justify their maintenance. Product design is the work of finding out which half, using prototypes, buyer conversations and evidence, while changing your mind is still cheap.
Overview
Discovery, prototypes and scope decisions that stop teams building the wrong thing.
Product design sits earlier than interface design. Before anyone picks a grid or a typeface, somebody has to decide which customer problem is worth a year of engineering payroll, what the first release must prove, and what evidence would show the bet was wrong. That is the work we do, and it takes weeks rather than quarters.
We run discovery as a sequence of falsifiable claims. Each claim gets the cheapest test that could break it: a concierge run behind a landing page, a clickable prototype in front of ten buyers, a spreadsheet model of unit economics. Claims that survive enter scope; the rest are recorded as things you deliberately chose not to build.
Enterprise products have a second audience that consumer products do not: the procurement, security and administration functions that decide whether the thing can be bought at all. We design the tenancy model, role matrix, audit trail and onboarding path alongside the customer-facing flows, because those are what stall deals in month nine.
- 31 down to 9
- Backlog items surviving discovery for the Halden Group partner portal MVP
- 14 weeks
- First problem interview to production release, Brightmoor Foods ordering app
- 3 of 11
- Assumptions that failed testing before any engineering budget was spent
Capabilities
What this covers
Six areas we staff properly. If your problem sits outside them, the honest note at the foot of this page says so.
Opportunity framing
Problem interviews with buyers and users, mapped against your commercial model, producing a ranked set of opportunities that each carry a stated size, a confidence level and the evidence behind them.
Assumption mapping and testing
We list what must be true for the product to work, sort by risk and unknown-ness, then break the top items with prototypes, fake doors or manual concierge runs before engineering time is committed.
MVP definition and scope control
A first release defined by the decision it must inform rather than the feature list a stakeholder read out. Everything else lands on a deferred list with the reason for the cut recorded next to it.
Service and operations design
The parts of the product that are people rather than software: onboarding, support escalation, exception handling and the back-office screens that make the customer promise deliverable on a bad day.
Enterprise readiness design
Tenancy models, role and permission matrices, audit trails, SSO and data-residency behaviour designed early, because these are the things security review and procurement stop deals on.
Instrumentation and success metrics
One primary metric, three supporting counters, and the events needed to compute them, specified before build and wired through PostHog or Amplitude so the first release can actually be judged.
Deliverables
What you get
- Opportunity map with sized, evidence-ranked problems and a recommended bet
- Assumption test log recording what was tested, how, and what the result changed
- Clickable concept prototype validated with at least ten buyers or end users
- MVP scope definition with an explicit deferred list and the reasoning per cut
- Service blueprint covering onboarding, support and exception handling
- Measurement plan with event schema and decision thresholds for release one
Stack
What we build it with
- Figma
- FigJam
- Dovetail
- Maze
- Amplitude
- PostHog
- Mixpanel
- Miro
- Linear
- LaunchDarkly
- Framer
- Typeform
Process
How the engagement runs
Two-week increments against a written definition of done. You can stop at any increment boundary and keep everything built so far.
Frame the bet
Two to three weeks establishing the commercial goal, the customers it depends on, and the claims that must hold true for the product to be worth building at all.
Break the risky claims
The cheapest possible experiment against the highest-risk assumption. Some run in a day; a concierge pilot with real customers and manual fulfilment may run three weeks.
Shape the release
Prototype the chosen direction from first contact to steady use, put it in front of ten to fifteen users, then cut scope until it can be built in one quarter.
Design the operating model
Blueprint the human steps, exception paths and admin tooling, then agree an owner for each with your operations and support leads before launch is scheduled.
Instrument and hand over
Event schema, dashboards and decision thresholds agreed with the delivery team, so the first release settles the argument instead of starting a new one.
When this is the wrong engagement
If the direction is already committed, funded and contractually fixed, product design becomes an expensive way to document a decision, and you should buy interface design and delivery instead.
FAQ
Questions we get asked
- How is this different from your UI/UX Design service?
Interface design makes a decided product usable. Product design decides what the product is: which problem, which customers, and what the first release must prove. Teams often buy both, running product design for six to ten weeks and then interface design alongside engineering.
- We already have a roadmap. Is this still worth doing?
Often more so. We treat the roadmap as a set of claims and test the three most expensive ones. A common result is that two items are promoted, one is cut, and one is replaced by something customers asked for repeatedly that nobody had written down anywhere.
- Who from our side needs to be involved?
A sponsor with authority to cut scope, someone in sales or account management who can open customer doors, and an engineering lead who can size options quickly. Expect four to six hours a week from the sponsor and rather more from the engineering lead during shaping.
- Will you tell us not to build something?
Yes, and we agree the decision thresholds up front so the recommendation is not a surprise. We have finished engagements with a written case for stopping; measured against a year of engineering payroll, that is the cheapest answer a discovery phase can produce.