The most expensive software is the kind nobody needed.
A good idea is not yet a good digital product.
Before development gets expensive, the problem, the users, the benefit and the riskiest assumptions have to be solid enough.
With Lens · takes about 3 minutes
Problem before feature
We first check which problem is actually relevant.
Risk shows up early
The most expensive wrong assumption should surface as early as possible.
Start small, and useful
The first scope creates real value, or learning you can trust.
When the solution is being designed too early
Typical situations
Deciding not to develop something can be a very good product outcome.
How solid is your product idea, really?
Idea
A possible solution exists. Problem, users and benefit still rest mostly on assumptions.
- A solution idea
- Many assumptions
- Little evidence
With Lens · takes about 3 minutes
Test the biggest uncertainty as early, and as cheaply, as possible.
Not every question has to be answered. The most expensive wrong assumptions should be known before they become software.
How O/S develops new digital products
Understand
Problem, users, context and today's alternative are made concrete.
Focus
The core benefit and the riskiest assumptions are prioritised.
Test
Assumptions are checked with conversations, prototypes, process analysis or technical tests.
Cut the scope
The findings become the smallest useful first version of the product.
Der Ablauf zuerst
We do not start with features. We start with the most expensive uncertainty.
Every wrong assumption gets more expensive once it has become software.
What changes withgood discovery
Problem
Investment starts with the need that matters.
Instead of starting from a feature list, the first question is which problem actually has to be solved, commercially and operationally.
Risk
Critical assumptions become visible early.
Uncertainties are tested before they turn into expensive development, procurement or internal coordination.
MVP
The first version has a clear purpose.
An MVP serves a concrete benefit or a learning goal. It is not an attempt to represent as much software as possible up front.
DECISION
Build, shrink or stop becomes a decision you can stand behind.
Whether you build, start smaller, use standard software, change course or stop follows from evidence you can trust, not from planning that never ends.
Calculate the cost of an open product decision
- How many hours per person go into an open product decision each week?
- How many people are regularly involved?
- How long does the decision stay open before a solid next step exists?
4Hours per person per week
3People involved
8Weeks until a decision
- ≈ 12 workdaysat 8 hours per workday
- ≈ 2.4 work weeksat 5 workdays per week
96 team hours until decision · 12 workdays until decision
This open product decision already ties up
3,648.00 €
The calculator looks at internal decision effort. It says nothing about market value, product success or development cost avoided.
Which uncertainty should you clear first?
Lens helps you sort the idea, the risk and the most useful next test.
Common questions
- We already have a concrete app idea. Do we still need discovery?
- Does O/S build MVPs?
- Can a prototype be enough?
- Does O/S look at build versus buy?
- What can happen after discovery?
- How do we measure product success?
Not automatically. If the problem, the users, the requirements and the technical direction are already solid enough, a focused build can be the right next step.
CONTACT
Which product decision can you not yet make with confidence?
Describe the idea, the problem and the biggest open question. You get a first reading of which assumption should be clarified before any development.