Embracing Uncertainty
This article explores the concept of embracing uncertainty in the software product development process.
It focuses on the strategic and core functional design aspects of the process in software product companies.
The concepts discussed here may also be applied to managing expectations, working with teams, and dealing with dynamic objectives in general.
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.
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.
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!
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.
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:
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:
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.
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:
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:
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.
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:
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.