CADS GmbH

Established Company

Show all Videos

Building Products with Purpose

Lukas Reinauer von CADS spricht in seinem devjobs.at TechTalk wie das Unternehmen das Thema der Produktentwicklung organisatorisch angeht.

By playing the video, you agree to data transfer to YouTube and acknowledge the privacy policy.

Video Summary

In Building Products with Purpose, Lukas Reinauer presents a practical toolkit that roots purpose in Meaning and Rationality and spans product, people, and process. He shows how to start with the “why,” define the problem and its risks, build a focused MVP, close the gap using requirements engineering plus either UX prototypes or code proofs‑of‑concept, and test early and often via verification and validation. He advocates involving developers and designers in customer conversations, steering customers toward problems not solutions, balancing technical debt with features, revisiting architecture, and treating regulation as a stakeholder with its own MVP; his prioritization rule is to weigh immediate customer value against development efficiency.

Building Products with Purpose: A field-tested Playbook from CADS GmbH for engineers who ship real value

Context and core thesis

In “Building Products with Purpose,” Lukas Reinauer (CADS GmbH) offered a compact, practice-driven framework for teams who want their technology to deliver actual value—not just output. He made a simple promise up front: you’ll leave with a toolset that helps you make better decisions day to day and at a strategic level—across features, products, portfolios, processes, teams, even entire organizations.

The backbone of that toolset is the deliberate pairing of meaning and rationality. Purpose doesn’t magically appear; it forms when you can answer “why” with conviction and then translate that into rational, verifiable action. In Reinauer’s world—medical technology—this is essential for safety and quality. But the principles generalize to any product organization.

Purpose stands on two legs: Meaning and rationality

Reinauer splits purpose into two complementary dimensions:

Meaning: the foundational “value to me, to users, to society.” It answers why the work should exist and what we can pursue with pride and joy.
Rationality: the chain of causal steps and action plans that convert intent into execution. It’s how “make the world better” becomes a specific, doable next step.

This duality protects teams from two traps: aimless activity without a north star, and lofty mission talk without a plan. It’s also a through-line that connects every practical recommendation in the session.

From problem space to solution: The ever-moving target and the gap

Why does product development feel so much messier than early whiteboards suggest? Reinauer referenced the classic gap dynamic: at the outset we barely know where we stand, our target space is fuzzy, and the “bullseye” shifts as we learn. With each user conversation we refine direction—often away from our initial trajectory. The result: learning loops, course corrections, and occasional detours.

The industry’s toolkit is well known: requirements engineering, usability/UX engineering with click-through prototypes, and proof-of-concepts (PoCs) in code. Each has strengths and blind spots:

Requirements conversations help, but remain hypothetical if customers can’t yet operationalize their own problem.
UX prototypes sharpen understanding, but don’t deliver value in the field.
Code PoCs yield real learning signals and sometimes immediate relief, but incur technical debt to be tidied up later.

Reinauer’s message: deploy these instruments deliberately, guided by meaning-derived rational plans. Not every feature needs an elaborate UX process. Not every PoC should aim for production readiness. Choose the lightest method that closes the information gap you actually have.

The product playbook: From “why” to proof

1) Start with why: Clarify the problem, don’t pre-sell a solution

The most important question is “why should this exist?”—what problem, for whom, and how urgent is it? Reinauer cautioned strongly against slipping early into “how we’d solve it,” then writing requirements to justify that preconceived design.

A practical trick from the talk: solve on paper first. Sketch the problem, structure the flow, and deliberately think against a paper process before you let technology preferences harden decisions. It keeps you reversible while the stakes are low.

2) Address risk early

In medical technology, every user requirement carries risk. What if load times are too long? What if calculations are wrong? These aren’t afterthoughts; they belong at the start. The build sequence should rationally reduce risk step by step.

3) The right MVP: Solve one urgent problem thoroughly

Minimal Viable Product doesn’t mean “a bit of everything.” It means “solve the one core problem well.” One of Reinauer’s most grounded points: users often care far more that the core calculation or function works reliably than about a pristine identity system or storage layer behind the scenes. MVP means delivering relief where it counts; the rest can mature later.

4) Choose prototypes deliberately: UX click-through or code PoC?

Selecting the right prototype is about the information gap and complexity you face:

If the user’s problem is fuzzy, a quick UX prototype helps uncover language, flows, and expectations.
If the key question is whether engineering can realize a certain framework or computation, a code PoC provides the signal you need.

The crux is your test goal: what specific risk do you want to eliminate with minimal effort?

5) Test as early as possible: Verification vs. validation

Two test axes—fundamental in medtech, broadly applicable elsewhere—anchor build confidence:

Verification: does the product meet its own specifications? Example: is the wall hook fastened with the intended force?
Validation: does the product solve the user’s real problem? Example: does the hook hold when you hang on it?

“You can do this for any product—software, hardware, medtech.”

The recommendation is blunt: run these tests early, run them often, and whenever possible, run them with real users. That’s how you burn down blind spots in requirements, architecture, and interaction.

6) Embrace iteration as the norm

Teams make mistakes. Users make mistakes. Environments change. That’s why agile exists: to continuously re-check assumptions, adjust decisions, and respond to new realities—without losing sight of purpose.

People as a force multiplier: Collaboration that creates understanding

Put developers and designers in the room with customers

A standout cultural pattern at CADS—and one of the session’s most actionable tips—is to embed engineering and design directly into customer conversations. Not only do product roles grasp nuance; implementers do, too. They hear the friction, ask clarifying questions, and internalize the “why.”

Reinauer’s personal yardstick: he’s proud when developers challenge his proposal with user-grounded arguments—“because the user needs X.” That’s lived purpose: shared product understanding beats hierarchy.

The MVP mantra: Pressure-test importance and urgency

There’s a line at CADS that has become an inside joke: “Is this really MVP?” It encodes disciplined prioritization—probing how important and urgent a feature truly is. Some things can explicitly wait until after we learn more.

Keep customers at the problem description level

Customers often offer implementation ideas or design sketches. Valuable—yet risky if they crystallize into premature specs. Reinauer’s approach: appreciate the input, but preserve the team’s freedom to solve the problem with its UX and engineering expertise. Collaboration, not design-by-committee.

Technical debt vs. new features: A shared prioritization

At CADS, prioritizing debt versus novelty leans on experienced engineers and transparent conversation with the customer: which features will matter soon, and which can remain lean for now? This wards off over-designing corners that won’t pay back yet.

Reassess architecture—especially when it’s inconvenient

Architecture tends to ossify, particularly in regulated contexts where documentation changes are costly. Reinauer’s warning: frequently ask whether yesterday’s architectural choices still hold. Late corrections often cost more than an intentional re-cut earlier.

Embrace: Demo progress, expand ownership

A high-yield ritual: weekly developer-led demos directly with customers, with immediate feedback. It builds pride, visibility, and anticipation. Equally, celebrate customers’ test effort. Anyone who’s ever played an early-access game knows the feeling of being “in early”—it bonds people to the product and motivates them to improve quality.

Process without dogma: Plan just enough, think like a regulator

Documentation isn’t the enemy—it protects people

In medtech, documentation is essential—sometimes you’ll produce as much paper as code, and that’s appropriate. Also, beware false dichotomies: running sprints doesn’t automatically make a team agile; good documentation doesn’t make it waterfall.

“Plan as much as needed”—based on product, regulation, organization

The right planning density factors in:

Product type and risk profile
Regulatory demands
Team and organizational mode

Whatever you plan, keep stakeholders aligned. Sneaking in new timelines without clear communication breeds confusion and friction.

Treat regulation as a stakeholder—with its own MVP

A liberating reframing from the talk: treat regulation and process like another stakeholder—with requirements, risks, and a defined MVP. Just as CI/CD pipelines fulfill automated process needs, you can deliver regulatory artifacts in the smallest valuable increments. That makes work items tractable and stops “documentation” from becoming a single boss fight at the end.

Decisions with reasons: Optimize along two axes

Reinauer advises rationalizing product choices along two axes:

What immediate value does this feature deliver to users—right now?
How efficiently can engineering deliver it?

Optimize across both to avoid pushing low-value, expensive scope into releases. This matters especially when you don’t ship every two weeks and release windows expand.

A compact, practical playbook

We distilled the core moves from “Building Products with Purpose” by Lukas Reinauer (CADS GmbH) into operational checklists you can apply directly.

Product: From purpose to impact

Clarify the why: which problem, for whom, how urgent?
Solve on paper first: sketch before you implement—stay reversible.
List risks: what happens if a requirement isn’t met?
Define the MVP: solve one central problem reliably—leave back-end perfection for later.
Choose your prototype: UX click-through for understanding gaps; code PoC for feasibility questions.
Test early/often: verification (against specs), validation (against user problem)—ideally with real users.
Iterate: continuously test assumptions, hold the course, correct the course.

People: Spread understanding, grow ownership

Put engineers/designers in user conversations—shared understanding forms in dialogue.
Ask the MVP question: do we need this now, or later—after we’ve learned more?
Keep customers at the problem level—retain solution autonomy within the team.
Balance tech debt consciously—based on what will matter soon.
Regularly challenge architectural decisions.
Demo progress and celebrate testers—amplify ownership and motivation.

Process: Agile without labels, regulatory without baggage

Set planning depth by risk, regulation, and organization.
Proactively align stakeholders—make timeline changes explicit.
Treat regulation as a stakeholder—define an MVP for artifacts/processes.
Prioritize across “user value now” and “engineering efficiency.”

Lessons learned for engineering teams

Purpose is two-dimensional: without meaning you lack direction; without rationality you lack execution. You need both.
The gap is normal—requirements, UX prototypes, and PoCs each close different parts of it. Choose the minimum that answers your question.
V&V aren’t medtech-only—they’re universal. Verify you built what you said you would; validate it solves the human problem.
Culture is product power: direct user exposure for the team and the right to challenge assumptions lift decision quality dramatically.
Documentation is process value, not bureaucracy for its own sake. Managing regulation like a stakeholder keeps you both safe and shippable.
Good prioritization follows two axes: user value today and delivery efficiency. That’s how you curb costly scope drift.

Conclusion

“Building Products with Purpose” by Lukas Reinauer (CADS GmbH) isn’t a buzzword talk—it’s a working set of tools. The core idea—tie meaning to rational action—distinguishes mere activity from real impact. Teams that follow this playbook will decide more clearly, build more purposefully, and test in ways that matter: ensuring they truly solve human problems—verified, validated, and with a team that doesn’t just talk about purpose, but practices it.

More Tech Talks

More Tech Lead Stories

More Dev Stories