Deep Tech Doesn't Need Beautification. It Needs Customers.

Harri Kiljander, CEO & Design Strategist

‍

Why design thinking matters most when your technology is cutting-edge

Recently I had the pleasure of speaking at Aalto Startup Center, Aalto University's startup incubator, which helps early-stage founders, many of them coming straight out of university research labs, turn their ideas into businesses. My audience was a curious gathering of early-stage deep tech team members, and my topic was product design for startups: turning ideas into relevant and appealing experiences.

It was a great session, with sharp questions and lively experience sharing between the startup teams. It also reminded me why this topic deserves more attention in the deep tech community than it usually gets. I've spent three decades at the intersection of complex technology and real-world users, as a design lead at Nokia, F-Secure, and Yousician, as a design advisor at the EuropeanPioneers startup accelerator, and along the way earning a doctorate in interactive digital media in Otaniemi, at what is now Aalto University. So here is a written version of the main topics we covered.

Deep tech: when "Can we build it?" comes first

A deep tech startup is built on a genuine scientific or engineering breakthrough, not just a new business model or another app layered on existing technology. Think quantum computing, new materials, synthetic biology, medical AI, battery chemistry, or advanced sensing. The core technology often comes from years if not decades of academic research, and the founders frequently include the researchers themselves.

In Finland, many of these teams start their journey through Research-to-Business funding, where university researchers get support to explore whether their research results can become a viable business. It's a critical phase. The science may be world-class, but nobody knows yet who will pay for it, what problem it can help solve in practice, or what the sellable product should actually be like.

That's exactly where deep tech teams face a double risk. A typical software startup mostly asks: Will anyone want this? A deep tech startup has to ask that too, but it's also still answering: Can this even be built? With long development cycles and expensive R&D, the technical question tends to swallow all the attention. The customer question gets postponed to "later, once we can make the technology work."

That approach is a costly risk. And it's the one design thinking is built to prevent.
‍

‍
Design is not about making things pretty

Let's clear up the most common misunderstanding first. When founders hear "design," many may think of logos, colors, and glossy user interfaces for consumer applications. Those matter, but they're the visible tip of the iceberg.

A design is a concept or proposal for an object, a process, or a system, created with a purpose, within a specific context, to meet certain goals under certain constraints. Two thousand years ago, the Roman architect Vitruvius said good buildings need strength, utility, and beauty. [https://www.architecturallyorganized.com/architecturally-organized/theoretical-thursday-strength-utility-beauty/] That definition of good design still holds even for contemporary products, although we’ve added some extras like usability, safety, simplicity, longevity, innovation, and sustainability.

My own favorite definition of design is a bit shorter: Design is your best possible educated guess, validated.

The key word is validated. Design thinking isn't about having brilliant ideas. It's about systematically finding out which of your ideas are wrong before they get expensive.

‍

Build, measure, learn, but build prototypes, not (yet) products

Many founders know Eric Ries's The Lean Startup and its Build-Measure-Learn loop: you turn ideas into a product, measure how (early) customers respond, and learn from the data to refine your ideas. [https://en.wikipedia.org/wiki/The_Lean_Startup]

For deep tech teams, I suggest one small but important edit to that loop: replace "product" with "prototype."

If your "product" requires two years of lab work, you can't afford to run the loop with the real thing. But you can build prototypes of the experience: a clickable mock-up of the industrial dashboard, a storyboard of how a hospital would order and receive your analysis, a mock report showing what your AI's output would look like to a technician. These may cost only days, not years. They let you put something tangible in front of real customers and users and learn whether you're solving the right problem.

What comes out of the loop isn't just "ideas" anymore. It's validated, improved, corrected, and sometimes scrapped ideas. Scrapping a poor idea after a week of prototyping and testing is a victory. Scrapping it after two years of intensive development would be a crisis for your startup.

The economics are well documented. Barry Boehm's classic "Rule of Ten" in software engineering holds that fixing a problem costs roughly ten times more at each later stage: a fix that costs 1 in design phase costs 10 in development and 100 in production (Software Engineering Economics, 1981). The same pattern holds for physical products. German engineering guideline VDI 2247 from the Association of German Engineers describes a "Rule of Ten" for hardware: the cost of fixing a defect grows roughly tenfold as a product moves from design and development to manufacturing, and again once it's delivered and in use. [https://www.designsociety.org/download-publication/27665/bug_or_feature_m%C3%B6glichkeiten_und_grenzen_des_fehlermanagements_in_der_produktentwicklung] For a startup with 18 months of runway, that isn't an abstract ratio. It's the difference between finding product-market fit and running out of money.

‍

Who is your user? (And who is your customer?)

This was the question I kept returning to during the talk, because in deep tech the answer is rarely simple.

Deep tech startups often sell to organizations: hospitals, utilities, industrial manufacturers, public agencies. In B2B markets, the person who uses your product is often not the person who decides to buy it, and neither of them is necessarily the one who pays the bill. Decisions are usually made by buying groups of executives and experts in very different roles, from CFOs to manufacturing process managers to CISOs, over months or years, and tend to be skewed toward rational arguments rather than emotional ones. Your end user, your economic buyer, your technical evaluators, and your procurement officer all have different needs, concerns, and definitions of value.

Understanding this landscape isn't optional. The good news is that the toolkit is mature and practical:

• Personas help you make different user groups and decision-makers concrete and keep them in the room during your product and marketing decisions.
• Customer journey maps show how a person actually moves through awareness, purchase, use, and renewal, and where the pain points and "moments of truth" are.
• Jobs-to-be-Done frames needs as "When I…, I want to…, so I can…" statements, which keeps you focused on the progress people want to make rather than on your features.
• The Value Proposition Canvas connects your product's planned pain relievers and gain creators to your customer's actual pains, gains, and jobs.

As for gathering the insight itself: talk to relevant people. Qualitative interviews and early concept tests with a handful of well-chosen buyers and users will reveal most of the major issues. Five people are better than one; one is better than none. Quantitative methods like surveys, analytics, and A/B testing become powerful later, when you have a pilot customer and enough users to measure.

One important caveat: don't be too dogmatic. No startup needs to run every discovery method in the book. The tools are there to answer questions, not to generate paperwork. Pick the method that answers the most pressing uncertainty with the least effort, learn, and move on.

‍

The researcher's trap

There's one pitfall I sometimes see in research-based startups. I raised it with the Aalto audience, drawing on a UX/UI design project we did for a University of Helsinki life sciences data spinoff.

When researchers design a product, they may naturally design it for someone like themselves: an expert who understands the underlying science, appreciates detail down to the fifth decimal, is comfortable with complex data, and wants every parameter adjustable. The result is often a tool that's impressive in a lab demo or scientific conference presentation.

But the actual users in a customer organization are frequently not postdoc-level researchers. They may be doctors with four minutes between patients, lab technicians processing dozens of samples a day, plant operators on a factory floor, or sustainability managers at small companies with no deep background in the field. They don't want the full scientific picture. They want a clear answer, a trustworthy recommendation, and a simple next step.

In other words, your technology can be deep while your user experience stays simple. Hiding complexity well is itself a design achievement, and one of the strongest competitive advantages a deep tech company can have. You can always have the full details and parameters available for the curious, or you can craft a separate interface for the research-minded customer teams. The question is whether the people who will actually use your product can understand it, trust it, and fit it into their daily work.

‍

Why this matters now

Design has always paid off in business. McKinsey's research found that companies making the best use of design grow revenues and shareholder returns at nearly twice the rate of their industry peers. [https://www.mckinsey.com/capabilities/tech-and-ai/our-insights/business-value-of-design/overview] But for deep tech startups, the stakes are sharper.

Investors increasingly expect evidence of customer demand, not just technical milestones. Competitors, including big incumbents, keep raising the bar for user experience, and consumer-grade experiences are reshaping what professionals expect from business software too.

Meanwhile, AI has fundamentally changed the economics of validation. At Alpha Design Partners, we work AI-natively across the design process: AI tools help us turn rough ideas into clickable prototypes in hours instead of weeks, transcribe and synthesize dozens of user interviews in a fraction of the time, and draft personas, journey maps, and test scripts that designers then sharpen with real insight. For a deep tech startup, that means you can run more build-measure-learn loops on the same runway.

But there's one thing AI can't do for you: meet your customers. Synthetic users and AI-generated personas can be a useful starting point, but they only reflect what's already known. The surprises that save startups, the unexpected workaround, the real reason a pilot customer won't buy, only come from talking to real people. AI can make validation faster and cheaper, but it doesn't make it optional.

‍

How we can help

Alpha Design Partners is a strategic product design and AI-native DesignOps consultancy based in Finland. Over the years we've worked with startups, research projects, and global industrial and consumer companies such as Vaisala, KONE, Glaston, and Yousician on service design, user research, UX/UI design, and brand development, often in exactly the space where complex technology meets real-world users.

For early-stage deep tech teams, one of the most effective ways to start is a Design Sprint: a focused, time-boxed process where your team maps the business challenge, sketches solutions, decides on a direction, builds a realistic prototype, and tests it with real users, all within a few days. You start with something vague and finish with real user feedback and a tangible prototype to show investors, partners, and your own team.

If you're turning research into a business and want to make sure you're solving the right problem for the right people before investing years in building the complete solution, I'd be happy to have a chat. Send me a message here on LinkedIn or email harri@alphadesignpartners.com.

‍

First we observe, then we design.
‍

P.S. If you'd like to see how AI-native DesignOps works in practice, you can watch the recording of our recent webinar (in Finnish) on speeding up product design work in the AI-native era.