This is 2nd article of series Backward Thinking in Problem Solving (Backward Thinking in Problem Solving — Part 1: Introduction). We are usually given problems to solve, which might make understanding problem further appealing as the immediate step. However, what we want to start any project with should be objectives.
The first step of any project is planning, which include setting objectives. Not only when we work backwards but also in any problem-solving framework, objectives are critical to the success of project as good objectives describe what success look like and will be used as north star through out the process.
If you start a project by dwelling into problems, you might get bogged down by numerous issues at the end of analysis phase. Only a few of these are worth solving or can be solved within your time frame. You want the problem analysis to help you find promising solution, not just root causes.
Stay relevant
It feels good to analyse problems when we start any project.In a past project that has a new knowledge domain, I made the mistake of exploring all related topics. Having many problems in the end, I had to spend more time on prioritising them and the work required more billable hours. I definitely learnt about the domain but something wasn’t right when client had to pay for all those hours. I should have had understood which specific problems contribute to the problems and final solution. The mistake can be avoided if I set out to collect data with clear objectives.
It is comfortable to think about problems without the constrain of objectives. However, in working backward we make having solution as first priority by planning our objectives. With objectives, we are better at choosing the method to collect and analyse data. The dilemma of trying to understand the root cause and collecting a wide range of data in analysis phase will be discussed further in the next article.
Use Design Criteria
Design criteria often act as the intermediaries between objective and solution. You don’t want to have tunnel vision when focusing on solution early, but also want something more specific that help you come up with solutions digging deeper into a problem. You might want to ask more question to validate whether design criteria works for your customers. Think about what kind of solution (instead of what solution) might help solve the problem.
Use design criteria to stay broad enough, before focusing on specific solutions.
Focus on the Unchanged
Many companies have their missions remain unchanged for a long time, even decades but their product portfolio change. The reason is because their mission is tied to human behaviours. The solution change quickly but human behaviour change much slower.
Good objectives
As objectives are not solutions, they rather describe the goals and ambition you want to achieve without limiting the scope by indicating which technology we have to use. As these ambition can be vague, a good objective need to have three factors:
-
Direction: E.g.We want to expand our insurance business to New South Wales farming community.
-
Measurable Target: In 5 years, we want to own 70% market of farming insurance nationwide.
-
Design criteria: We want to focus on medium and large-size farming business firstly and build customer base through broker and financial advisors.
Case study: Amazon
Working backwards is practiced in Amazon. New products by Amazon start with customer first. Werner Vogels mentioned this in his article Working Backwards.
-
Start by writing the Press Release. Nail it. The press release describes in a simple way what the product does and why it exists — what are the features and benefits. It needs to be very clear and to the point. Writing a press release up front clarifies how the world will see the product — not just how we think about it internally.
-
Write a Frequently Asked Questions document. Here’s where we add meat to the skeleton provided by the press release. It includes questions that came up when we wrote the press release. You would include questions that other folks asked when you shared the press release and you include questions that define what the product is good for. You put yourself in the shoes of someone using the product and consider all the questions you would have.
-
Define the customer experience. Describe in precise detail the customer experience for the different things a customer might do with the product. For products with a user interface, we would build mock ups of each screen that the customer uses. For web services, we write use cases, including code snippets, which describe ways you can imagine people using the product. The goal here is to tell stories of how a customer is solving their problems using the product.
-
Write the User Manual. The user manual is what a customer will use to really find out about what the product is and how they will use it. The user manual typically has three sections, concepts, how-to, and reference, which between them tell the customer everything they need to know to use the product. For products with more than one kind of user, we write more than one user manual.
Using Lean Startup
Lean Startup by Eric Ries, a popular startup framework, has some similarities with Amazon principles. When we combine them together, we have following steps in defining objectives of product development:
-
Create landing page containing information similar to Press Release, and describe the customer experience.
-
Validate the product further with customer research. Use the insights to figure out the customer experience of the product. Describe it to customer in the landing page. Dropbox did this in a video. You need to figure how the product can be valuable and usable.
-
Improve the landing page with FAQ and User manual after validating the product. The FAQ and USer Manual contain product requirement for engineering.
Think slower to go faster
It feels comfortable to go with objectives passed by stakeholder without reiterating them to fulfil important details. The next time you start any project, make sure to spend time on setting clear objectives before doing doing research or development of solution. My preferred ways is to practice asking following questions and redefine objectives until they check all Yes boxes:
-
What does success look like?
-
Can I describe the success to people outside the project team (to make sure it is understandable)?
-
Is the objectives quantifiable in any measurement?
-
What are the hypotheses in your objectives that I can validate?
-
Are the objectives focused on something unchanged in future or might it be irrelevant soon?
-
Are my customers part of the success? What do they look like when using the solution?
In the following article, I will talk about Analytical Framework in helping you measure process logically when working backwards.