A strong digital product rarely begins with a feature list. It begins with a clear understanding of the work the product must do — for customers, for the organisation and for the people expected to operate it every day.
That distinction matters more than it sounds. Analysis by the product analytics firm Pendo, covering 615 customer accounts, found that roughly 80% of features in a typical software product are rarely or never used, while around 12% of features generate 80% of daily usage volume (Pendo, 2019 Feature Adoption Report). The problem is almost never a shortage of ideas. It is the absence of a method for deciding which ideas deserve engineering time — and which are expensive answers to questions nobody asked.
What follows is the route we use at Emerge360 to get from a promising idea to something people rely on. It is the same loop that underpins all of our services: understand, design, build, learn, improve.
Start with the decision, not the interface
Before screens or technology choices, define the change you want to create. Which behaviour should become easier? Which operational bottleneck should disappear? What evidence will show that the product is useful?
A focused product statement gives research and design something concrete to test. It also gives you a way to say no. Without one, scope tends to expand along the path of least political resistance rather than the path of most customer value.
A useful format is a single sentence with three parts: for [this person], in [this situation], we will make [this outcome] measurably easier, and we will know it worked when [this indicator] moves. If you cannot complete that sentence, you are not ready to brief a design team — and any UI/UX work commissioned at that point will be decorating an undefined problem.
Note that the indicator should describe the customer's world, not the project's. "Ship the portal by Q3" is a schedule. "Cut the time from enquiry to quotation from four days to one" is an outcome you can design against.
Turn assumptions into a small learning plan
Every early brief contains beliefs about users, value and feasibility. Write them down, rank the riskiest and decide what evidence would increase confidence.
The ranking step is the one most teams skip. Not all assumptions are equal: some are cheap to test and low-consequence, others sit underneath the entire business case. Sort them by how badly this hurts if we are wrong multiplied by how uncertain we currently are, then work down the list.
Interviews, service mapping, analytics and lightweight prototypes can answer important questions before a build budget is committed. Eight customer conversations and a clickable prototype cost a fraction of a development sprint and routinely change what gets built. The point is not to eliminate uncertainty — it is to make sure the expensive decisions are the well-evidenced ones.
This is also the stage to be honest about feasibility. If the product depends on data your systems do not currently produce, or on an integration that no supplier has agreed to, that is a risk to test now rather than discover in week nine of a custom development programme.
Design the service around the product
The interface is only the visible layer. Content ownership, support, fulfilment, permissions and data all shape the customer experience.
Mapping front-stage and behind-the-scenes work prevents a polished product from creating chaos internally. A booking flow that takes thirty seconds for the customer but generates a manual reconciliation task for someone in finance has not removed work — it has moved it somewhere less visible and harder to measure.
Three questions expose most of these problems early:
- Who keeps this accurate? Every piece of dynamic content and every price, availability or status field needs a named owner and a realistic update rhythm.
- What happens when it goes wrong? Refunds, corrections, disputed records and failed payments are part of the service, not edge cases to handle later.
- Who can see and change what? Permissions modelled late tend to be modelled badly, and retro-fitting them into a live platform is expensive.
Answering these before build is what separates a website from a working service. It is also why our web development engagements begin with editorial workflow and ownership rather than page templates.
Build in slices that deliver value
A useful first release is not the smallest collection of features. It is the smallest coherent journey that a real customer can complete end to end.
The distinction is practical. A half-built journey teaches you very little, because no user reaches the end of it. A narrow but complete journey — one product category, one customer type, one region — produces real behaviour you can learn from within weeks.
Working this way depends on being able to release frequently, and the industry data suggests that many teams cannot. In DORA's 2025 research into software delivery, only around 16% of organisations deployed on demand, while roughly 24% deployed less often than once a month, and about 44% needed more than a week to get a commit into production (DORA / Google Cloud, State of AI-assisted Software Development, 2025). Long lead times do not just slow delivery — they slow learning, because every correction waits for the next release window.
Two habits keep slices honest:
- Define "done" as released and observed, not merged. A feature nobody has used has not yet produced information.
- Instrument before you launch, not after. Retro-fitting analytics is how teams end up arguing about what happened instead of looking it up.
Treat launch as the start of evidence
After release, combine behavioural data with customer feedback and operational insight. Decide what to improve, what to remove and where to invest next.
Removal deserves particular attention, given the Pendo finding above. Most product backlogs contain more candidates for deletion than teams are comfortable admitting, and every unused feature carries an ongoing cost in testing, support, documentation and cognitive load for the next developer who touches it.
The evidence also needs to include friction that customers never report. In ecommerce, Baymard Institute's meta-analysis of 50 studies puts average cart abandonment at 70.22%, with surprise costs at checkout (39%) and forced account creation among the leading causes — and it estimates that fixing documented checkout usability problems is worth an average conversion uplift of around 35% for large sites (Baymard Institute). Very few of those abandoning customers ever fill in a feedback form. The evidence is in the funnel, not the inbox.
Scalability is as much about a repeatable learning rhythm as it is about infrastructure. A monthly cycle — review the numbers, review the qualitative signals, agree what changes, ship it — will outperform a heroic annual redesign almost every time.
What this looks like in practice
For Bridge Engineering, a UK supplier of industrial hose, cable and reel solutions, the work was less about adding features and more about making specialist products findable and specifiable — catalogue structure and product presentation first, so the buying journey could actually be completed. For Stitched Equestrian, the defining decision was where product customisation should live: putting logo upload and placement configuration on the product page rather than behind checkout kept a complex journey coherent.
Both are examples of the same principle. The product decision came first; the interface followed.
Where to go next
- If the immediate question is what to build and in what order, that is product and service design work.
- If the constraint is a platform that makes change expensive, start with building platforms that stay useful as you scale.
- If part of the opportunity involves automating repeated judgement, see where AI automation creates real value.
- See how this has played out for other organisations in our portfolio.
Sources
- Pendo, 2019 Feature Adoption Report — https://www.pendo.io/resources/the-2019-feature-adoption-report/
- DORA / Google Cloud, State of AI-assisted Software Development (2025) — https://dora.dev/
- Baymard Institute, Cart Abandonment Rate Statistics (meta-analysis of 50 studies) — https://baymard.com/lists/cart-abandonment-rate
Useful digital work is a continuous loop: understand, design, build, learn and improve.