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

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:

• 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:

1. Does the product address the appropriate problem, pain point, or desire? In other words, does it target the right opportunity?
2. Is the company focusing on the right market and does it have the capability to sufficiently access that market?
3. 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.

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.

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.

References

What’s SDLC? by Erçin Dedeoğlu

10 Reasons Your SaaS Business is Creating a Poor Customer Experience by Nils Vinje

The MVP is dead. Long live the RAT. by Rik Higham

Buyer Journey vs Customer Lifecycle: a Comprehensive Guide by Johan Patel

Why Multidisciplinary Teams Design Better Products by Andrew Weiman

Embracing uncertainty was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.

A product trio is a concept of team setup aimed to drive product discovery, strategy, and any aspect of design. The key aspects are:

• Cross-functional team to observe the same opportunity from different angles
• Team ownership and responsibility for the outcome (not only output)

At mobilityONE, a newcomer to a crowded market, it was crucial to innovate at every level of the offering, from the core value proposition to the user-facing and visual details. I was the product manager on the mobilityONE team, so I insisted on making sure we get it right by using the product trio approach.

In this blog post, I’ll describe the product design process used to create strategic product decisions. I’ll also describe the value of the product trio approach to designing the solution and clarifying the value proposition.

Team Setup

Working collaboratively in a group, rather than distributing individual responsibilities, makes a solid foundation when making far-reaching decisions for software products. The three key roles are:

• the product manager,
• the designer,
• and the engineer

This approach allows for a holistic view of the product and its requirements, ensuring that all aspects of the product are considered during the design process and that the product satisfies customer needs while bringing value to the business. The idea is to get everyone in the same room on different aspects of the product and share an awareness of what’s possible.

That does come with some meeting overheads, but that’s O.K. in the first stage when efficiency without efficacy is plain stupid. Would you want to efficiently climb the wrong tree?

We used this approach to reassess our value prop and create a product that meets the needs of operations leaders and fleet managers while being flexible and customizable to adapt to any organizational structure or specifics.

The Goals and the Process

We used this approach in the very early stage of product development, when the core value prop, features, and design were still in the earliest phases and still highly open to change.

A few goals for the process were non-negotiable:

• Strong feedback loop — being able to apply the learnings from later-stage phases to the core concepts and even the core product value proposition
• Being bold — we couldn’t build yet another “me too” product. We needed to be brave and disruptive in our approach, which includes disrupting our own best decisions from the previous sessions
• Ensuring we are radically honest about whether we’re building a strong value proposition including how well can we communicate it

Our product trio team consisted of the founder, who had a deep understanding of the industry, the UX/UI designer, who brought 20+ years of creating magic, and two very experienced software architects with expertise in both the functional and technical design of various B2B solutions. I was in the role of product manager, bringing SaaS co-founder and CTO experience to nail the value prop and drive the process.

The group as a whole was responsible for the outcome, and everyone on the team was obliged to contribute to all aspects of the task at hand, including functional design, user experience, flow, visuals, etc. The more outside the box their contribution, the better. Certainly, that required large doses of mutual respect and permission to disagree, facilitation, conflict management, resilience, and every aspect of psychological safety. What’s life without a few good fights and storytelling scars?

This approach allowed us to consider all aspects of the product, from the user interface to the technical requirements, and ensured that the final product was a well-designed solution that met the needs of our target audience. More importantly, the crazy and whacky ideas from “non-experts” on a given topic were more than once actually brilliant out-of-box contributions.

During the process, we deeply challenged the value proposition. We recognized that the biggest competitor in our space was actually Excel, which many fleet managers turn to when the limitations of their solutions can’t handle the specific needs of their organizations. Therefore, we needed to create a product that offered greater flexibility and customization options than existing software solutions, matching Excel’s flexibility while providing structure and reliability.

We started the process with a design and functionality offering of a standard, feature-rich, typical SaaS product, that would probably reach the 10th page on Captera. Understanding we’ll never be able to catch up and find our space under the sky, we challenged every assumption during our process. We needed to create an offer that “their bosses could not resist”.

We iterated very aggressively, and after a few iterations came to a flexible solution that was inspired by analytics and interactive visualization web applications. The solution allowed users to extend the standard data points for fleet management with information specific to their organizational needs, and use it all to build reports, dashboards, or alerting systems. Instead of building feature-rich software, we made a flexible platform that allowed our users to greatly avoid the need to use Excel for management, attribution, and reporting.

The product design process itself was iterative and involved weekly sessions and the use of Figma as a quick prototyping tool. Because we were in the early stages of product development, we did not limit the number of iterations but focussed on getting it right. This approach allowed us to pivot quickly and make changes as needed, resulting in a product that met the needs of our target audience and offered greater flexibility than competitor solutions, and greater reliability and transparency than Excel.

Results and retrospective

Every person on the team made at least one cornerstone contribution in what resulted in a totally redesigned functional offering, an unrecognizable pivot from the original direction. The resulting software product was redesigned from the initial, feature-rich design of B2B software, to a very dynamic dashboard-like platform for querying the underlying data, automated reporting, notifications, and alerts. While we addressed the same opportunities, the product itself was redesigned from the ground up.

We made sure to stay longer in ideation mode, only to rapidly settle with a satisfying solution that felt right. That would never have happened without explicitly challenging every team member to contribute in areas significantly out of their personal comfort zones and competencies.

Key lessons

There is not a single recipe that guarantees success. Rather, think about the best practices and principles, and apply them to your situation. Should you try the same approach, include the following key ingredients in the mix:

• Gather multiple people from different backgrounds and roles into a cohesive team — and ensure that you have SME, a designer, and a technologist
• Allow time to nail the solution by staying in discovery mode and don’t rush prematurely into development. Reassess who your customer really is, which budget you are tapping into, and whether you are solving the right problem
• Don’t take any single person’s point of view for granted, but insist on validating it
• Ensure that every member’s contribution is equally substantial in and out of areas of that member’s expertise or comfort zone
• Constantly reassess how value for the customer translates into value for your business

Conclusion

In conclusion, the product design process is a critical part of any software development process.

Using a cross-functional approach to discovery and functional design opened different perspectives which set the foundations to create a valuable solution.

To ensure contribution from every team member, it’s important to set the stage that promotes brave and disruptive moves.

The iterative process allowed us to pivot quickly and make changes as needed, resulting in a product that met the needs of our customers while bringing value to the business.