How to Super-Charge Your Startup Innovation With Design and Product Thinking
Acknowledgement: this blog post was done in collaboration with Emma Lundgren, Experience Design Consultant at ThoughtWorks, who contributed ideas and discussions on design thinking and product validation.
This blog post is the third sequel in the story, which captures my journey of building the “Magic of tidying photo” app . The previous post introduced the app idea, which attempts to solve the problem of tidying up photos on your phone for good.
This post shares about product thinking and design thinking come together to help innovate my product idea. Specifically, I reflect on setting up the project to fail fast, adopting a lean and iterable strategy, and how design thinking and product thinking play a role on ideating in search of a suitable solution.
Stop, Breathe and Design Think!
A wise colleague of mine summarised Design Thinking in one sentence — “ it is the art of navigating uncertainty to discover a solution.” And another very wise designer said:
“Designers don’t search for a solution until they have determined the real problem, and even then, instead of solving that problem, they stop to consider a wide range of potential solutions. Only then will they converge upon their proposal. This process is called design thinking”
(or Design Doing which Don Norman prefers more now).
— Donald Norman
Years of working in an innovating space in start-ups and high-growth businesses have taught me about my achilles heel: starting with the solution. Often, we in the software industry are biased towards a technology or solution we are good at. We are often in the mode of finding the problem that fits the awesome solution we have in mind, also known as the “a hammer looking for a nail” approach. In other words, by focusing on the solution, we miss the most important thing about product development: solving a problem for someone.
To be fair, successes can still be had when focusing primarily on the solution, as opposed to the problem. PageRank, Google Search’s underlying engine, is an example. This is especially true in disruptive innovations, when customers might not even recognise the problem or that they would ever need the innovative solution.
However, the limitation of solution-first approach is when we focus too much on the solution, we often fail to have empathy for the customer’s pain points. We might also ignore important nuances from the customer view, which might play an important role in successful adoption. It can end up being a very expensive mistake to make (for example, the story of Juicero).
My challenge was now to address my achilles heel, and use Design Thinking to help guide me.
Focus on problems — and solutions come automatically
“People don’t want to buy a quarter-inch drill. They want a quarter-inch hole.”
—Theodore Levitt
The key to successful products is summarised very well by Steve Jobs in his response to a harsh audience question after learning from his own mistakes in the 90s:
“Start from the customer experience and work backward to the technology.”
In the context of designing a photo clean-up app, while speaking to friends and coworkers, the problems and the nuances they experienced slowly revealed itself. For example, some of them struggled with hitting the delete button (a problem). Others struggled with finding enough energy to do so regularly (another problem).
Once problems are understood, solutions often come naturally. Problems are often more permanent than a solution, taking that into consideration can make a solution more future-proofed. For example Netflix was more able to pivot when streaming services became more popular and accessible, when they realised that they weren’t in the “delivering DVDs to peoples’ homes” business, they were in the “entertaining people wherever they are” business. They made their solution about a fundamental problem, not about the way the solution got delivered.
Finding solutions are still challenging. There are many ways solutions can be generated, such as through using analogies.
Use analogies to discover feature ideas
Ideas are rarely born out of nowhere. One of the principles of lateral thinking is to look to other places that solve a similar problem already. Where is tidying up already happening? What is so rewarding about it? What are psychological principles behind it? And how could these principles be used in a photo tidying app?
For instance: tidying a kitchen. Why do we tidy up kitchens? What intrinsic reward is at work here that motivates us to do so?
It probably has something to do with how visible the kitchen is. It is in our face every day, and so are the pains we associated with untidy kitchens, for example, restricted access and slowing down our meal preparation. In turn, these ideas and questions provided clues to how I might improve the chance of users using my app regularly.
I had started to discover some first principles of my app idea. Such as, bloated photos on the phone are highly visible on the first load of the app.
Now, there are many ideas that might solve the problem. How do I know if such ideas are actually useful? To answer these questions the next steps were learning and validating.
Failure is acceptable only if you learn from it
As we know, small ideas and great ideas both have the ability to die. Some of the most successful products have failed miserably in their earlier attempts. WD-40 and Angry Birds are some well known contemporary examples.
Sometimes, enormous success can be disguised as crushing failure early on. The Grange wine — arguably the most famous Australian wine and the only heritage-listed one, attracted horrible reviews for the first few years of its life. The important thing is to keep going and to keep learning. It can be crushing to get bad feedback early on but imagine how Max Schubert felt when his baby ‘Grange’, which he had conceived in secret, received “universal dislike” by leading wine critics when first revealed. If you feel your blog posts aren’t getting the best traction, think about Max Schubert and say these words to yourself: keep going!
While I was cautiously convinced that the problem of tidying photos was, and still is, real and worth solving, I was not convinced that the solution, or a particular iteration of the solution, will be successful.
Pushing through with the belief that a particular solution was going to be successful was a recipe for confirmation bias. I wanted to get the product out there, validate it fast and correct the course, before it was too late or too expensive to change direction.
I had to think of a way to get the solution to a “good enough” stage and get feedback quickly and iterate on it.
Know what good enough means for you
Product development is kind of like going for a hike with no map. You know roughly where you might be going, but you need to look at signals that could tell you that you’re heading in the right direction. Validating the problem hypotheses is like looking out for signals on your hike to your goal. Important signals can differ from product to product and the method you use to look also varies. The important piece is to keep going and not get blinded by confirmation bias.
The most important questions to ask at this stage in my case were (Inspired by Marty Cagan);
- Do people want it and would they pay for it? (Is the product valuable?)
- Can people use it? (Is the product usable?)
Don Norman claims, with support from other scientists on the matter, that most of our thinking and decision making is subconscious, and that this is especially important when designing a product. Also:
“We know we can’t count on our customers to tell us what to build” (from Marty Cagan’s book Inspired)
Given Marty Cagan’s thinking, I needed to show my users what the solution might be and then listened to what they had to say about it. There were no facts to be found in my house so I needed to get out and talk to people, or as Steve Blanks would put it:
I needed to generate information to fill my sketchy picture of a map. I applied the “interview people on the street” technique. Except, they were not quite “on the street”, they were generous friends and colleagues.
Feedback I received helped me to re-approach the solution before committing to building it. For instance, early validation showed me the need to add features to highlight “safe deletion”. Some users thought it was important to trust the app before they could try it out fully.
Trust was now my main challenge. This helped me focus on solving the trust issues of the app. For example how could photos be safely deleted or reverted, and how could I make this clear to the user?
I had a clearer solution hypotheses and this led me to move on to think about the next question:
How could I build this?
Pretotyping is incredibly useful — until it isn’t
Prototype or pretotype validation is extremely helpful, but so is getting the product out to the hands of the customers.
In some cases, and this was especially true for this stage; prototypes can only give you so much. There is a limitation to what I could learn to progress from here. I knew enough about the problem and solution to start validating the real deal — through testing in the wild.
There is probably no better way to validate WD-40 than spraying it on an actual rusted surface to understand how well it’s performing.
In my case, I applied one simple rule: once I had solved for a certain pain point, I moved on to release it out, as soon as I could. I did this even though the solution was quite basic.
Once the product was out in the wild, it was time to think about how to actually measure progress. To do that I had to decide which goal would be suitable for an early stage app.
You can only improve what you can measure
A lean development process requires a specific goal to measure progress against. Or better yet, a simple goal.
For me, the first goal wasn’t about growth. Growth hacking and metrics like increasing traffic needed to wait.
I found Sam Altman’s thought quite useful here, from his book “Customer Love is all you need”, true scale only comes when you have found “100 users who love your product than 1 million who like it”.
After all, the ultimate success of the app would mean it actually solved a problem for users (which implies adoption). The secondary goal is, then, to ensure it solves such problems for enough users.
My goal is therefore to find 100 users who love the product. 100 users that use the app because it actually solves a problem for them. In my case, it is about finding users who engage with it regularly to really tidy up photos.
Importantly, with this goal now clearly defined, I can decide what tracking is needed to make my goal measurable. I chose the number of deleted photos as a proxy to measure the actual outcome.
Having decided on a simple goal and a simple way to measure progress towards that goal, I decided to move on.
Finally…iterate, iterate and iterate
The project started late last year when I got some holiday break. During the 10 months I had:
- 123 code commits
- 6 revisions on the Apple App Store
The project has been stopped and restarted many times. All the way, it has taught me how important it is to pay attention to an iterable set up.
One thing that stood out to me as the most important thing, was the Continuous Delivery principle. Basically, building the product in thin-slice and release into production in small chunks as many times as possible.
If you’re considering building an app remember these things:
- Go through the app publishing process as soon as you can, with the minimal information you have (for example with a working build, media assets, description and manifest)
- Find the most painful part of that process and attempt to do it as many times as possible
- Make sure you have a plan to rinse and repeat. Many times I spent the 80% effort to set something up, but failed to follow through on the 20% remaining effort to make good become great
- Document, document and document. Document for others and for yourself. Document as code has been useful. I also found it useful to document the context as much as I could so after a 6 month freeze, everything didn’t look alien to me.
What all of these mean for you
In this blog, I have discussed many ways design thinking and product thinking helped super charge my product innovation.
The key to all of these principles, in my reflection, is really about focusing on the authentic problems for users and the ways solutions be designed to be actually useful, through continued testing and learning. It can make a difference towards innovating and making your product success more likely.
