Design

Decide What to Build Before You Build It

Discovery, prioritisation and rapid validation that turn a long wish list into a sequenced roadmap — so the first release is the one worth shipping.

  • Validated before it's built
  • Prioritised against real evidence
  • Prototypes tested with real users
  • Roadmap your team can defend

Is this you?

Four Signs You Have a Product Problem, Not a Design Problem

These aren't fixed by better screens. They're fixed by deciding differently.

  • Your backlog is a wish list, not a plan

    Everything is a priority, nothing is sequenced, and the loudest stakeholder usually wins the sprint.

  • You shipped features nobody uses

    Engineering time went into things that tested well in a meeting and flatlined in the analytics.

  • Scope keeps growing and launch keeps moving

    The MVP has quietly become version three, and nobody can say what would happen if you cut half of it.

  • You're about to build something expensive on an assumption

    The business case rests on a belief about users that has never actually been tested with any.

Overview

Strategy, Validation and Sequencing

The work that happens before interface design, and decides whether it was worth doing.

Most failed products aren't badly designed or badly built. They're well-executed answers to a question nobody checked. Product design is the discipline that asks the question properly: who has this problem, how are they solving it today, what would make them switch, and what is the smallest thing we can put in front of them to find out.

We start with discovery — customer interviews, market and competitor review, analytics on the existing product if there is one — and turn what we learn into a prioritised set of opportunities rather than a feature list. Each one gets sized against user value and engineering cost, so the roadmap you end up with is a sequence you can defend to a board, not a list of everything anyone has ever asked for.

Then we validate before committing. Design sprints and clickable prototypes let you test the risky assumption in a week rather than discovering it in month five. What we hand over is a definition of the first release that everyone has agreed to, a roadmap for what follows, and the evidence behind both — plus a measurement plan so the next round of decisions is made on data rather than on the same instincts that produced the wish list.

Capabilities

What's Included

Nine areas of product work. Which apply depends on whether you're starting, scaling or rescuing.

  • Product Strategy & Vision

    A defined position, target user and value proposition that gives every later decision something concrete to be measured against.

  • Discovery & User Research

    Customer interviews, competitor review and analytics interrogation that establish what people actually do rather than what they say in surveys.

  • Opportunity Mapping

    Problems and unmet needs mapped and sized, so the roadmap starts from opportunities rather than from a list of requested features.

  • Feature Prioritisation

    Structured scoring against user value, business impact and build cost — with the reasoning written down so decisions survive a change of stakeholder.

  • Design Sprints

    A week to take a risky assumption from idea to tested prototype, so the expensive question gets answered before it becomes an expensive build.

  • MVP Definition

    The smallest release that genuinely tests the proposition, with an explicit list of what's deliberately excluded and why.

  • User Flows & Concept Design

    End-to-end journeys and concept-level screens that make the product tangible enough to test, price and argue about usefully.

  • Roadmap & Release Planning

    A sequenced plan tied to outcomes rather than dates, with the dependencies and trade-offs of each release made visible.

  • Metrics & Product Analytics

    Success metrics defined up front and instrumented at launch, so the next prioritisation round runs on evidence instead of instinct.

Deliverables

What You Receive

  • Product strategy document with positioning and target user definition
  • Research findings from customer interviews and competitor analysis
  • Opportunity map with problems sized and prioritised
  • Scored and sequenced feature backlog with the reasoning recorded
  • MVP definition including an explicit out-of-scope list
  • Tested clickable prototype covering the primary journeys
  • Release roadmap tied to outcomes and dependencies
  • Measurement plan with success metrics and instrumentation spec

Stack

Tools We Work In

Chosen to keep the evidence and the decisions somewhere your team can still find them a year from now.

Design & Prototyping

  • Figma
  • FigJam
  • Framer
  • ProtoPie

Research & Validation

  • Maze
  • UserTesting
  • Dovetail
  • Optimal Workshop

Analytics

  • Mixpanel
  • Amplitude
  • GA4
  • Hotjar
  • Microsoft Clarity

Planning

  • Miro
  • Notion
  • Linear
  • Jira

Our Process

How We Shape a Product

Six phases. The point of the first three is to make the fourth cheaper.

  • 01

    Discovery & Research

    Customer interviews, competitor and market review, and analysis of whatever product data already exists — separating what users do from what stakeholders believe they do.

    Deliverables: Research findings, competitor review, current-state analysis

    2–3 weeks
  • 02

    Strategy & Opportunity Mapping

    Findings turned into a positioning statement, target user definition and a map of the problems worth solving, each one sized rather than just listed.

    Deliverables: Product strategy document, opportunity map, success metrics

    1–2 weeks
  • 03

    Prioritisation & MVP Definition

    Opportunities scored against value and cost, then cut to the smallest release that genuinely tests the proposition — with the exclusions written down and agreed.

    Deliverables: Scored backlog, MVP definition, out-of-scope list

    1–2 weeks
  • 04

    Concept Design & Prototyping

    User flows and concept screens assembled into a prototype real enough to test, price and disagree about productively before anyone writes code.

    Deliverables: User flows, concept designs, clickable prototype

    2–3 weeks
  • 05

    Validation & Roadmap

    The prototype tested with people in the target market, findings folded back in, and the release sequence set against outcomes rather than arbitrary dates.

    Deliverables: Validation report, revised concept, release roadmap

    1–2 weeks
  • 06

    Evolution & Measurement

    Post-launch, we read the instrumentation rather than the anecdotes, and reprioritise the roadmap against what usage actually shows.

    Deliverables: Analytics reviews, reprioritised backlog, roadmap updates

    Ongoing

Engagement

How We Work Together

Three shapes, depending on how much is already decided and how fast you need an answer.

  • A fixed-scope run through research, strategy, prioritisation and a validated MVP definition. Best before committing an engineering budget.

Fit

Who This Is For

And, just as usefully, who it isn't for.

Ideal for

  • Founders about to commit a serious budget to an unvalidated idea
  • SaaS teams whose backlog has outgrown anyone's ability to sequence it
  • Companies that shipped features and saw no movement in the numbers
  • Businesses replacing an internal process with a product other people will pay for
  • Product teams that need an outside read before a board or funding decision
  • Organisations where scope keeps growing and launch keeps receding

Not the right fit if

Why DM Solutions

What You Get Beyond the Deck

Four commitments aimed at the decisions, not the documents.

  • We'll Tell You Not to Build It

    Sometimes discovery says the market isn't there or the problem isn't painful enough. That answer costs weeks instead of a year, and we deliver it plainly.

  • Evidence, Not Opinion

    Every prioritisation call is traced back to interviews, analytics or a tested prototype — so decisions survive the next change of stakeholder.

  • Scope Cut, in Writing

    The MVP comes with an explicit out-of-scope list. Naming what you're not building is what stops it quietly reappearing in sprint four.

  • Instrumented From Launch

    Success metrics are defined before the build and wired in at release, so the second round of prioritisation runs on data rather than on memory.

Proof of work

Products That Found Their Market

Engagements where the roadmap changed shape before the budget did.

Testimonials

What Clients Say About Working With Us

  • The rebrand and UI overhaul completely changed how customers perceive us. We went from looking like a scrappy startup to a company enterprise buyers take seriously — without losing our personality.

    Kwame Asante

    Founder, Beacon Analytics

  • They didn't just hand us pretty mockups — they built a design system our whole team can run with. New screens that took weeks now ship in days, and everything finally looks like one product.

    Marcus Bell

    Head of Product, Northwind SaaS

Questions

Frequently Asked Questions

The six that come up before every product engagement.

  • Product design decides what to build and in what order; UI/UX design decides how it looks and behaves once that's settled. Product design owns strategy, discovery, prioritisation and MVP definition. UI/UX owns information architecture, wireframes, interface design and the design system. Most engagements run product design first, then hand a validated definition into interface work — and we do both, so nothing gets lost between them.

Ready to Find Out If It's Worth Building?

Tell us what you're planning and what it rests on. We'll come back with a discovery plan, a timeline and a fixed-price proposal.

Detailed proposal within 48 hours. No commitment required.