Why design matters (before anything else)

Design is not just how something looks; it is a way of deciding what to build and why before you spend scarce time and money. In innovation work, design connects four lenses— desirability (do people want it and in what context), feasibility (can we make it safely and reliably), viability (does the model work at a sensible cost and price), and sustainability (what are the environmental and social impacts across the lifecycle). When these are explored together from the start, you avoid the most common failure mode: building an elegant solution for a problem that users don’t actually feel.

At the very beginning you’re operating inside the fog of uncertainty. You can’t see far ahead because big questions are still open: is the user problem real and urgent, which behaviours matter in context, what technology path is credible, what standards apply, and which route to market is practical? The only way through the fog is evidence. Design shrinks uncertainty by turning assumptions into small, observable tests like quick interviews, rough prototypes, bench rigs, or pilot workflows that let you watch real behaviour. Each loop converts unknowns into knowns, and the fog thins enough to take the next confident step without pretending to see the entire route.

Good design also reduces hidden technical and operational risk. Choices about materials, tolerances, assembly, and packaging are design decisions as much as they are engineering ones, and they carry cost and quality implications. Bringing manufacturing considerations (DFM/DFA) into the conversation early saves painful redesign later. In regulated spaces (for example, medical devices), design integrates usability, risk controls, and documentation so that what works in a test also passes inspections and protects users in the field.

Design also make stakeholder conversations concrete: a clinician, operator, or distributor can react to a flow or mock‑up far more reliably than to an abstract description. Typical traps are easy to spot.

A simple plan gets you moving: (1) schedule five conversations with real users in their real setting; (2) sketch two or three ways your idea could work and test them quickly; (3) map the end‑to‑end journey including installation, training, maintenance, and support; (4) list the top risks across user, technical, commercial, and regulatory domains and assign one early test for each. Repeat this loop. When the evidence improves, invest more. When it doesn’t, change direction while the cost of change is still low.

Quick takeaways: Design is how you decide what not to build. Treat it as the front‑end of risk management, not as decoration at the end. Keep artefacts small and decisions visible. Bring manufacturing and regulatory thinking in early so feasibility and safety grow alongside desirability.

1) Fail Fast, Fail Cheap (“kill your idea”)

Think of this as a friendly stress test. Before building anything big, you and the team imagine it’s six months later and the project has flopped. Why did that happen? Write down the reasons - missed user need, a part you can’t source, a regulation you ignored, a budget that ran out. Now flip each reason into a small test you can run this week. The aim is not to be negative; it’s to find weak spots early while changes are still quick and inexpensive.

Keep the process simple. Time‑box it to an hour, ask everyone to contribute quietly at first, then group similar ideas and pick the handful that would hurt most if true. For each top risk, pick an owner, a tiny experiment, and a date. Example: “We may be solving a ‘nice‑to‑have’. Test: call five target users and ask how they solved this last week. If no real workaround exists, we’ve probably mis‑framed the problem.”

You’ll know it worked if you leave with a short list of experiments on the calendar, not a long document. Revisit the list every couple of weeks. Close items when you have evidence, not just a gut feel. The habit of testing early and cheaply keeps momentum high and prevents costly late surprises.

2) Understand the User (User-centred from day zero)

Most failed products are smart solutions to problems people don’t truly feel. Early research keeps you honest. Start by talking to real users in their real setting. Ask about the last time the problem happened, what they did first, what took too long, and what “good” looks like from their point of view. Avoid “Would you use this?” and aim for stories: “Tell me about yesterday’s shift,” “Show me the form you filled,” “Walk me through your workaround.”

Turn what you hear into a clear problem statement: “For X (who), when Y (situation) happens, they need Z (outcome), because… (evidence).” Build the smallest sketch or click‑through that lets people try an idea. Watch where they hesitate and what they ignore; that behaviour is better data than opinions. If your users include people with access needs, plan for that from the start like how you recruit, how you run sessions, and how you design.

Keep outputs short and useful. One page with top findings, a few quotes, a photo of the environment, and the next test you’ll run is enough. Repeat the cycle as your understanding deepens. Research doesn’t slow you down; unfounded assumptions do.

Additional Resource: UK Service Manual — practical user-research guidance. GOV.UK

3) Assemble the Right Team (and culture)

Great teams have habits that make learning safe and fast. Two simple rules cover most of it: it’s okay to say “I don’t know,” and it’s okay to challenge ideas. When those are true, problems surface early and decisions improve.

Early on, you need a small mix of skills: product (what are we trying to achieve and how will we know), design (turn insights into things people can try), engineering (make it real and reliable), and commercial (who will buy, at what price, through which channel). Bring in regulatory or IP expertise if your domain needs it. Keep meetings light: a weekly show‑and‑tell of the smallest working thing, a short retro on what helped or hurt, and a clear list of decisions made and why.

If work gets stuck on one person or bad news travels slowly, fix that system. Write down how you work together, share context in writing, and pair people on risky tasks. You’re building culture with every behaviour you reward or ignore, design it deliberately.

Additional Resource: Google’s Project Aristotle summary on team effectiveness & psychological safety. Rework

4) Intellectual Property (IP) basics

IP protects the value you create, but it should follow your business plan, not lead it. There are four main tools: patents (how something works), registered designs (how it looks), copyright (creative works, code, content), and trade marks (your brand). You may use one or several depending on what makes you unique and how you’ll make money.

Lay the groundwork early. Make sure contracts say the company owns what employees and contractors create. Keep dated notes, prototypes, and code history. Run a basic patent and trade‑mark search so you know the landscape. Remember: “Can we patent this?” and “Are we free to sell this?” are different questions. You can be novel and still collide with someone else’s rights.

Pick a strategy that fits. A provisional patent can secure a date while you refine. Some know‑how is better kept as a trade secret. If looks are part of the edge, register the design. If you plan to license to a bigger player, expect talks about field‑of‑use, territory, minimum sales, and royalties. Keep records tidy so due diligence later is boring, in a good way.

Additional Resource: UKIPO “IP Basics” overview. GOV.UK

5) Be Receptive to Change

Change is the rule, not the exception. Customer needs shift, new evidence lands, components go out of stock, regulations update, teammates’ availability changes. Thats how founders usually start as chief problem‑solvers.

Start by agreeing what’s fixed and what’s flexible. 
Fixed (guardrails): user safety, ethics, legal and regulatory duties, data privacy, quality standards, and staying solvent. These don’t bend. 
Flexible (degrees of freedom): scope and sequencing, the exact implementation, tooling, meeting cadence, and who pairs with whom on a task. Writing this down removes friction as people can change the flexible parts confidently because the guardrails are clear.

Build in Plan B triggers. Pre‑define thresholds that flip you to an alternative: “If supplier A can’t meet lead times by this date, we move to the approved alternate.” “If error rate stays above X after two iterations, we simplify the feature.” Triggers remove emotion from tough calls and keep momentum during uncertainty.

Use brief daily check‑ins to surface blockers; keep weekly demos open so anyone can see the smallest thing that works and offer feedback. When external changes land, say, a standard updates or a component is discontinued, treat it like any other signal. Name an owner, run a quick impact scan, and decide: adapt now, schedule, or watch. 

6) Technology Obsolescence

Parts get discontinued. Standards move on. A supplier merges and drops a line you rely on. None of this is rare; it’s normal. Plan for change from the start so you can upgrade on your terms.

Keep a simple technology roadmap that looks 12–24 months ahead. Link the user value you’re promising to the features that deliver it and the components those features depend on. Prefer widely available parts, watch notices from suppliers, and qualify a second source for anything critical. Design your system with clear interfaces so you can swap a module without rebuilding the whole product.

Operationally, name someone to own obsolescence. Maintain a short list of at‑risk parts with dates and actions. Review it quarterly with engineering and procurement so “last‑time buys” are a decision, not a panic. Budget a little for sustaining engineering. Ending a version should be a mini‑project with timelines and guidance, not an abrupt email.

Resource: Cambridge IfM — Roadmapping overview. IfM Engage

7) Budget Control

Cash buys you learning time. Know two numbers: monthly burn (cash out minus cash in) and runway (cash on hand divided by burn, in months). Review them every month. If burn creeps up or revenue slips, react quickly instead of hoping the next round or deal lands in time.

Plan for three futures: base, upside, and downside. Tie each plan to clear triggers. Example: “If monthly revenue is under £40k by March, pause hiring and shift two engineers to the feature that unblocks paying pilots.” This removes emotion from hard choices and protects the core mission.

Spend where learning is fastest. Fund work that produces hard evidence like passed tests, signed letters of intent, validated unit cost, rather than activities that “feel” productive. Keep a small contingency for surprises like certification fees or supplier issues. Clarity around money doesn’t slow you down; it keeps you in the game long enough to win.

Resource: YC guide to burn rate & runway; Sequoia’s “Extending Your Runway” memo. Y CombinatorSequoia Capital

8) Know your TRL (Technology Readiness Level)

Technology Readiness Levels (TRLs) give you and your partners a shared scale from 1 to 9 for how proven your technology is. TRL 1 is basic principles observed; TRL 9 is proven in real‑world use. The magic is in agreeing on the evidence required to move up a step.

Mark your current level honestly, then list what must be true to reach the next one. Early on that might mean a working benchtop demo and solid lab data. Midway you’ll need an integrated prototype running in a relevant environment with real users. Near the top you’re running pilots in production‑like settings and closing the loop on reliability, safety, and support. Tie funding to these gates so you only scale what’s ready.

Add the TRL ladder to your roadmap so everyone sees progress and gaps at a glance. It’s a conversation tool: clear, simple, and hard to game if you anchor it in real tests and documents.

Additional Resource: NASA TRL explainer (and formal definitions). NASA+1

9) Commercialisation

A product becomes a business when value flows reliably from you to customers and money flows back. Choose a route to market that matches how buyers already buy. Direct sales give control and feedback; distributors or retailers give reach; licensing lets a larger company commercialise your IP while you collect royalties. There isn’t one “best” route, pick the one your team can execute.

Map your assumptions on a single page (the Business Model Canvas works well). Who exactly is the customer? What job are you helping them do? How will they find you? What must be true about costs and price to make this worth it? Highlight the riskiest items and design tests. For pricing, start from value and alternatives, not cost‑plus. Early tools like the Van Westendorp method can hint at ranges, but real offers tell you more: will a prospect sign a paid pilot or a letter of intent?

In enterprise or regulated markets, expect longer sales cycles and extra proofs like security reviews, compliance, clinical or safety evidence. Factor that time and cost into your plan. If licensing, learn the basics: territory, exclusivity, field‑of‑use, minimums, and termination terms. You’re designing a system that makes and keeps promises so keep it simple and testable.

Resource: Strategyzer — official Business Model Canvas. strategyzer.com

10) De-risk Continuously (use a risk register)

Risk isn’t a one‑off exercise; it changes as you learn. A lightweight risk register keeps everyone honest and aligned. Write each risk, note how likely and how painful it is, and name an owner and a next action. Review the list regularly, little and often beats a big annual ritual.

Good registers are short and alive. They include technical and non‑technical items: user safety, regulatory hurdles, supplier dependency, key‑person risk, cash runway. Close risks only with evidence: a passed test, a second supplier under contract, an approval granted. Pair each mitigation with a date so you can see movement.

Visibility reduces drama. Share the heat‑map in leadership reviews and with partners when appropriate. When everyone sees the same picture of exposure, decisions get faster and surprises get rarer. That’s real de‑risking.

Resource: HM Treasury Orange Book — risk management principles (incl. example categories). GOV.UKGOV.UK

From Lab to Market (the non-linear reality)

Moving from a promising idea to something that succeeds in the real world is rarely a straight line. Expectations spike, reality bites, learning accumulates, and the mature product looks simpler than the early concept because the unnecessary parts have been carved away. Two models help set expectations: the familiar hype‑cycle (ideas rise to a peak of inflated expectations, fall into a trough of disillusionment, then climb a slope of enlightenment to a plateau of productivity), and the “valley of death” where projects stall between proof‑of‑concept and something customers can buy, use, and support.

Projects fall into the valley for predictable reasons. Funding and accountability change hands; academic metrics value novelty while markets value reliability and outcomes; prototypes work in the lab but struggle in messy, time‑pressed environments; and no one owns the hard parts between demo and deployment. The antidote is designing the translation steps on purpose and agreeing the evidence needed at each step.

A practical way to navigate is to pair stage goals with evidence gates. Early on, you are proving the problem and basic feasibility. Next you integrate the parts and show they work together in a relevant environment with representative users. After that come pilots in operational settings, attention to quality systems, supply chain, and support. Only when the evidence from pilots is strong do you invest in tooling, certification, and broad launch. Communicate maturity in plain language or with a scale like TRLs so everyone knows what “ready” means in your domain.

Partnerships matter. If you are spinning innovations out of a university, align with industry early. Co‑develop use cases with a partner who feels the pain and understands the buying process. Clarify IP ownership and licences up front, including field‑of‑use and publication timing, so publication and protection don’t trip each other. If you are inside a company, include operations and support early so the design you pilot is the design you can build and service at scale.

Finally, expect iteration. Standards will update, components will change, new competitors will appear, and your initial route to market may not be the one that carries you forward. Build for change: modular designs, replaceable components, clear interfaces, and a short decision log so the reasons behind choices don’t get lost. Treat surprises as signals. When reality contradicts the plan, adjust quickly and visibly rather than doubling down.

Quick takeaways: Plan the translation, not just the invention. Pair each stage with the evidence you’ll need next. Line up partners who live the problem. Prove demand with real offers, not just positive meetings. Build your product and your organisation to adapt because the path to market is non‑linear by design.

Resources: Hype Cycle overview; UK Parliament’s “Bridging the Valley of Death” report. Wikipediapublications.parliament.uk