Embracing uncertainty in the product development process

The strategic and core functional design aspects of the process in software product companies.

Marko Linke

Published in

UX Collective

7 min readJun 6, 2023

Inspirational photo of repeating layers of light reflecting in the mirror. — Photo by Diane Picchiottino on Unsplash

Typical Software Development Life Cycle

Software Development Life Cycle (SDLC) typically has a few phases. Obviously, before testing, the software should be developed, and before that, it should be designed and even thought about.

The urge for efficiency makes us want to do a phase once, and then proceed to the next phase without giving second thoughts and ever going back. Well, nobody’s perfect, so this often results in the software product failing in the market.

The old-school is the infamous Waterfall model, where the project goes through such phases, rigid and stiff.

The “perfect” flow in the Waterfall process. Each phase is followed by the next one, and there’s never going back — The Waterfall model

We kind of figured out that “accidents happen”, so we accepted that things go in the opposite direction as well. The feedback loop started to show itself.

In reality, there is always feedback or new information that flows from the later phase and feeds information back to the previous one, or even back to the root. — Feedback in the Waterfall process

That seemed like an unavoidable fact of life, but it was a disaster to manage. So, after a few iterations, we figured it out: It is about a circular process and evolution!

A Circular process takes into account that work happens in iterations and that every delivery actually feeds information back to the drawing board. — Software life cycle processes by ISO 12207

This works if the cycle is short. We agreed that we discover as we go, and that “I’ll know it when I see it” is a fact of life so we need to create something before fully understanding if there’s a problem with the plan.

But we often don’t apply the same level of healthy skepticism to the broader area in which we create software products, we don’t rethink our base assumptions, and treat them as ground truth.

This is especially important for product companies, i.g. SaaS. In that case, a company needs to make a well-thought, cohesive value proposition, which includes every aspect of the business. And, that makes a bigger risk to make a bad decision.

An alignment is needed among different aspects of the same offering to make it a well-rounded, cohesive story. For example, Sales, Product, and Finance, all have to be aligned — In a product company, every aspect must be done right, and together it needs to be a cohesive value proposition

In a software product company

To satisfy our customers throughout their journey from discovery to retention, we must perform in all aspects of the business, especially in those that touch on our customers. Here is a short list of examples of what can go wrong:

Market and user research — is there a market, and is it even looking for a solution?
Product strategy and value proposition — is it the right product?
Product development — will it be done right and managed right?
Customer care — how will it handle users’ needs and troubles?

Also worth noting, customers don’t buy software. They neither rent it. They hire it to do something for them as long as it is faster, cheaper, or more accurate than how they already handle the job. Software needs to address those core needs that are often hidden. It also competes with “do nothing”, and with “I’ll know it when I see it”.

Specific to software product development, here are some risks that software products encounter:

Does the product address the appropriate problem, pain point, or desire? In other words, does it target the right opportunity?
Is the company focusing on the right market and does it have the capability to sufficiently access that market?
What is the size and competitiveness of the market, and what will make your product stand out?

That means that risks to the overall success are both upstream and downstream from the software product itself. It also means that product teams need to work in collaboration with everyone that serves customers in whichever phase of the customer journey they are, i.g. marketing, sales, customer care, and even finance.

Success doesn’t happen in isolation. Everyone has to recognize and make an impact outside their own silos

Articulating uncertainty

Adopting uncertainty in our daily process has some huge benefits.

We already stick to some practices that prioritize our awareness of uncertainties, taking them into account, and addressing them at the appropriate time. Let’s consider a few examples:

Design sprint and Design thinking both have validation and feedback deeply in their core
Lean development’s rule #4, defer commitment, teaches us to constantly be ready to change the course
Story points in Scrum follow the Fibonacci sequence to remove false accuracy and ensure we plan accordingly

Uncertainty is like a suitcase that we need to carry through phases. Once articulated it helps us not to be in denial.

Addressing the risks of uncertainty

There are a few things we should have on our minds, and promote in our organization.

Identify assumptions disguised as assertions

Often we make a statement without even being aware we’re making an assumption. Consider the following plan:

“Add a route optimization to the map”

One often overlooked step is naming and testing assumptions. Such as:

Will the users expect that capability?
Will they prefer some other app for that?
Will it get the whole job done or just touch on a portion of it?
Will it return our investment? Why? How?

Now think about even larger assumptions left untested, such as “We can’t sell our product without building XYZ capability” or “Let’s expand to serve nurses, and not only doctors!”.

Become sensible to understand when your plan-building blocks are expectations, predictions, assumptions, or simply wishes. And thoroughly examine what conditions need to be true, in order for the assumption to be true.

Uncover what and how much is important to your customers

Remember that in the end somebody, a fellow human, will have to decide to take their money and give it to you. And the decision will be both reasonable and emotional, objective and subjective.

So, to have the whole truth, step out and pay attention to the value being created, rather than (only) internally on the effort invested. Measure the product being built, and not merely the ability to develop, predict and estimate.

This does not in any way mean we don’t mind the cost to build, the time to market, or getting ourselves better all the while. But the value to the business will not come unless we bring value to the customers.

Products need to create both Customer Value and Business Value.

A condensed, iterative, and collaborative process

Our sensors must be strongly attuned to what will bring value to customers and also bring value to the business, so if we need to answer questions that start with “But wait! Yesterday you said…”, then we better do. And we better do it sooner than later.

Short and iterative process gives us more chances to uncover and address false assumptions.

The waterfall process merely protects our ego. It doesn’t protect the customer from not getting what they need, nor it protects the vendor from scope creep. Unless the domain and solution are already deeply known, don’t use a process that can’t stand surprises.

In an ideal world, all phases would collapse into a single point, so that we address every aspect at once, and get feedback immediately — Squeeze the cycle into a focused cross-functional Workshop

One possibility is to try to compress the evolutionary circular process even further. Instead of having internal experts with strong boundaries between the types of work, bring the team together in a short, focused workshop, set the cross-functional sync process, collaborate on tasks, etc.

It is important to do it in a multidisciplinary setup. We want to catch all perspectives, but also not miss an opportunity that shows itself when you put everyone at the same table.

Discover solution, and keep discovering

There is a reason why there is the term “Product discovery” next to “Product design”. Unless working on a well-known problem and a proven solution, it is often both cheaper and more reliable, to gradually discover what the end product should have been in the first place, than even to try and do it all at once.

Remember, to defer commitment is a tool that first checks if the rock is solid before we trust it to cross the creek. There are stages of discovery that range from lower to higher commitment, and we should use the same approach. To broaden perspective, Product discovery is a business-wide process of applying a vividly articulated rule by Jim Collins, “Fire bullets, then cannonballs”.

Some actions to take are:

Continuously conduct customer interviews and stay alert on what brings value to customers and how much are they already paying to get the job done.
Test a clickable prototype with actual customers. And iterate on it
Slice the elephant, but don’t forget what’s your current goal for the end product
Test the feasibility and a Happy Path with a proof of concept. Handle the production-level exceptions later, when it makes business sense
Don’t overengineer (but don’t shoot your future foot also)

To conclude

It is important to stay alert and be ready to change course at all times during the project. Tracking success with customers as early on is a necessity and no amount of planning will guarantee success.

There are more ways for plans to go wrong than what we can or want to see, and a lot of it is out of our hands. Focusing on outcomes for the customers and value for the business helps, but it needs to be concretely articulated and measured.