Everyone familiar with the ‘Chaos Report’ knows that, in general, you only have 1 chance out of 3 to run a successful software development project. Additionally, about 60% of the features created in an IT product are never used. You can improve your chances in various ways, but statistically, those are the odds.
In this article, I would like to give a high-level overview of the method we use at The Master Labs to improve your chances of success. Keep in mind, the information presented here is a simplified version of reality, and every project can be different and may require different tools, techniques, and methods.
So, how do you build software that addresses a real business need (“building the right product”), and how do you build it so that it works great (“building the product right”)?
Many development teams have no clearly defined approach and are confused about all the options they can take. Some examples:
Should we run a design sprint to understand our users? How long should it take?
Should we do a development sprint to build features?
Should we build an MVP and do the build-measure-learn cycle?
There are so many (good) ideas, but which are best?
Many immature product teams struggle with the above questions and just want to start building. And before you know it, the team is building features that nobody really needs (but they do it in an agile way. Good!).
They are building the wrong product very efficiently.
In order to build products that matter, teams must find a way to effectively link the product discovery tasks (what to build) with the product delivery tasks (how to build it). In this article, we explain how you can do this.
One of the central beliefs of our method is that people use products and services to “Get a Job Done”. It is our task to build those products and services that help people to get the job done. So, this is where it all starts.
If you want to learn more about the “Jobs To Be Done” principles, do read the excellent (and free!) book by Alan Klement - When Coffee and Kale Compete – Become great at making products people will buy”.
Step 1 – The outside-in view: decide what services or products to offer to your customers to help them to “Get the Job Done”.
We call this first step the outside-in view. In this step, we evaluate the service or product through the eyes of the customer. It is important to realize that customers do not care about the way we implement the service internally. They only care about the actual interactions they have with the service or product.
The service or products a company provides are the company’s answer to the customer’s desire to get a job done. So, our first job is to find out what job the customer want’s to get done. Only then will we be able to design a service that truly helps the customer.
In addition, when customers consume our services, they will have good and bad experiences. It’s essential to gain insights into this customer experience. To gain this insight, we can apply some interesting design thinking techniques like user role mapping, customer journey mapping and creating emotional paths and identifying moments of truth.
This first step then tries to answer these three essential questions:
What do customers want – what is their Job To Be Done?
What services and products do others, and we, offer to fulfill this need?
How do our customers experience our competitors' and our own services?
We’ll use an example of a product that we’ve built for a customer. An online repository for training material in the racing sector. Let’s call it “Master Your Racing”. We identified several users for the application: Rookie, Pro, Trainer etc. and each of these has a specific Job To Be Done. For more information on user role modeling, please check our user stories training.
The Rookie’s Job To Be Done is defined as “I want to restore a 1967 Ford Mustang Shelby” and to do so “I want to become a better mechanic”. Our idea to support this user is to offer an easy way to find high-quality course material.
Filling out the above templates can be done in various ways, but we use some standard analysis techniques such as customer interviews, desk research, brainstorming sessions, and workshops.
By analyzing the customer journey through customer journey mapping and by creating an emotional journey map we can gain insights into the way the customer currently experiences the services. If we are confident the current options do not satisfy the customer, we might have a chance to convince him or her to try our new offering!
Later we can use the same techniques to evaluate the customer’s experience of our newly designed service!
Step 2 – The inside-out view: design the business services realized by people, processes, and applications
In this second step, we put on our ‘internal glasses’ to understand the inside-out view.
To offer these services to our customers we must realize them by hiring and training people, by organizing the work in business processes and by building or adapting applications to support these processes.
These are the three internal components of the service.
Because processes are a key part of the machine, it is useful to define them clearly:
A business process is a set of activities that delivers a specific result in support of the service.
A service can consist of or is supported by, multiple business processes and a business process can support multiple services. When looking at a business process, you’re looking ‘under the hood’ of the machine.
Let’s look at a small example for the Master Your Racing services. The following business processes support the Master Your Racing service.
Going from services to business processes that realize the services seems like an easy and trivial step – but, in reality this turns out to be a bit more complex.
Throughout our ample consulting experience we noticed that identifying the processes in an organization is not an easy task to get right. It seems that everybody has created their own interpretation of what a business process is or isn’t – but unfortunately, most are wrong.
At The Master Labs, we use a proven approach to process identification. Just remember, there -IS- a right way to elicit and define processes so that they are manageable and at just the right level of abstraction - and there are many wrong ways.
For more information on this topic, please keep an eye on The Master Channel, as we’re building a course on exactly that. Or if you want to get the details sooner, contact us for more information.
In the initial phases of the analysis, we try to avoid going into too much detail. So, instead of modeling each of the processes using a process modeling language like BPMN, we start with a much more basic description of the processes using a Turtle diagram or a process scope profile. We want to keep these initial discussions at an architectural level rather than drilling down into the details.
Based on this process architecture, we can identify the people working in the processes, and the applications that support the processes. At this point, we understand how the customer experience is realized by the underlying processes, applications, and people.
Additionally, during the customer journey analysis from the previous step, we identified some pain points and maybe we also identified several opportunities that may improve the customer experience.
It’s now time to improve the experience by solving problems.
Step 3 - Imagine a better customer experience
In the previous steps, we may have identified several pain points in the user experience, caused by problems with the machinery (processes, people, applications).
In this third step, we aim to improve processes, applications, and people with the explicit goal of improving the customer experience. To do so we apply a problem-solving methodology. In practice, there are multiple problem-solving methods but most of them share the same basic structure. We like to use the Business Analysis method.
If we identified multiple pain points or opportunities, we will apply this BA problem-solving process to every identified problem or opportunity. If you want to learn more about the BA method, check out our course Business Analysis Foundations.
Building a better customer experience (need) seems like a trivial task – but it’s far from that. Sometimes the problem looks like a maze of many intertwined problems - that seem impossible to solve.
A structured approach to business analysis helps a lot!
First, we start with the important challenge of understanding the question, and more importantly, understanding the context of the question. Before hacking away and redesigning processes or adding new features to a system we need contextual information.
We identify three levels of context - the strategic context, the project context and the context of the actual question of the assignment.
Next, we need to thoroughly understand and define the problems that must be solved. The goal is to find a problem worth solving. This involves consulting business experts to find out more about the area of concern to gain a deep understanding of the issues. This is also called root-cause analysis.
You put together the information you have gathered and analyze your observations and synthesize them in order to define the core problems (and root causes) that you and your team have identified up to this point.
In the next phase, we try to find the best solution to the identified problems. Typical questions to answer are “How might we …”-questions – this should help the team to generate ideas. There are literally hundreds of ideation techniques – of which some are discussed in our Business Analysis Foundations training.
But then the hard work is still in front of us. We have a problem worth solving and a solution that may work, it’s now time to prepare for roll-out and implementation. We’ll get to that in a minute.
The output of this phase is several ideas (both business and IT) that must be implemented to improve the services.
Step 4 - Story mapping: putting the pieces of the puzzle together
In the previous step, we defined the business needs of the solution from an internal and an external point-of-view. This solution could be business-oriented, such as a redesigned process, or IT-oriented, such as the automation of part of that process. In the context of this article, in step 4, we focus on IT-oriented solutions.
Business needs are often referred to as business requirements. To translate a business requirement into a software requirement, an analyst can create user stories. Usually, analysts will create many user stories.
User stories are used to describe the features that must be built for a user to complete an action. A user story often starts as a card or a post-it. The most important element of a user story is that it is used as a communication tool and acts as a pointer to the detailed requirements. It should tell the story of the journey the user is having throughout the system. User stories are a great technique. If you want to learn more please visit our user stories training on The Master Channel.
To understand the features, the team communicates about what must be built and how to build it. To do so the team uses all it takes to gain a deeper understanding of the required features. We use traditional requirements modeling techniques to build the support material – such as BPMN, Entity-Relationship modeling, DMN, CMMN, UML, wireframes, and other techniques. Whatever it takes!
For more information on process modeling and data modeling, please check our courses on processes and data.
The conversations about the user story may lead to new and smaller user stories that can be prioritized, estimated and built – this process is called user story splitting. Typically, teams try to define user stories that adhere to the INVEST principles.
We often had problems keeping track of the link between the customer experience, the identified pain points, the improved processes and the fine-grained user stories that are used in development. A few years ago, we started using story maps to visualize this.
In the beginning, we used the Story Map to capture and track the software requirements. Just recently we also started using it to track all business requirements. Do you have a business change that doesn’t result in a user story? Great, why not put it on the story map to keep track of how your service delivery is changing?
The story map becomes the central artifact that links both the product discovery dimension to the product delivery processes. It’s essential for every product team.
I would like to conclude this article with a quote by Guy Kawasaki:
Ideas are easy. Implementation is hard.
We truly believe that the presented step-by-step approach may help to fix the weakest link in your product team!