No product-market fit? Here’s 7 steps of how I pivoted a failed app
3 words: UX Research. The key is UX research.
TL;DR
After reading this article, you will have 2 key takeaways:
- What to do if a product doesn’t have product-market fit 😥
- How to do UX research for product pivoting 🧠
So… no one is using your product.
Long story short: my project Savvy, a calendar-based bookmark to remind people to read, failed.
I won’t waste time explaining why it failed here — let me just summarise it in one sentence: Savvy does not have product market fit. (If you don’t know what is PMF, check this article)
In fact, 90% of startups fail and 34% fail because of no Product-Market Fit. So if you’re reading this while struggling with your own project (e.g. no user retention, no paying user), don’t worry it’s very common. We’re all in this together.
And here I’m going to show you what I did to overcome the predicament.
What should I do if no Product-Market fit?
UX research. UX research. UX research.
UX research is a powerful tool to understand users and the problem you’re solving.
There’re two types of UX research you can choose from: problem-oriented or user behaviour-oriented.
The above graph explains which way you should go for based on a dialectical process.
Problem-oriented UX research
As you can see, people who should go for the problem-oriented way are those who have a problem truly painful enough. What these product have discovered are true pain point of users and they have indeed market potential.
In other words, these startup have a great value proposition (i.e. a unique selling point), but they just failed to deliver it, due to perhaps a bad UX or lack of research. Some signs could be the app having lots of sign up but very high churn.
In these situation, founders should further understand the problem you have already defined, instead of scrapping their current value proposition and think of a new one.
User behaviour-oriented UX research
On the other hand, user behaviour-oriented is for startup that have addressed a wrong problem — often these problem they’re solving lack actual market potential, or is just a problem that isn’t that painful except to the founders.
So in this situation you want to further understand how your targeted audience behave, like understanding their demographics, asking them what are the daily routine, these insight can help us reveal their other underserved pain points and help us rebuild a better value proposition.
User behaviour-oriented UX research is also what I think as the last step before ‘pivoting’. Pivot, in the simplest definition, means redefining your core value proposition.
Therefore behaviour-oriented research should be more bold and creative than a problem-oriented one, as we are no more sticking to the old problem statement defined, instead we’re exploring a new one.
But notice! Pivoting is not about just scrapping you old idea. Instead of just throwing away the existing product and brainstorm another idea, pivot does not mean accepting failure and move on, but more like diagnostics and fix in a trial-and-error process.
By pivoting you are relying on existing resources and insights to rethink your core value proposition. If you’re building an app, then you should pivot based on insights from the failed app, like user data generated from the app, existing user feedbacks and other quantitative or qualitative evidence that could suggest a new potential product perspective.
For Savvy, I chose the wrong way.
If you’re really not sure which UX research approach your startup should go, no worries because for my startup Savvy, I initially started in a problem-oriented manner only to realise later that behaviour-oriented is a more suitable one (the realisation process is mentioned later), but we are still able to adapt and modify the UX research goal at a later stage.
So that’s probably enough theory for you — time to see how I did my UX research for Savvy. 👇
Full story of Savvy’s pivot UX research
I did this UX research in March this year and used Notion for documentation. I will use some Notion page screenshots to visualise the writing. If you want to look at all the Notion documentation I wrote during the UX research, you can DM me :)
And also I should mention that the Savvy team is in no way resourceful. We’re a team of 4 working part-time on this project, with two teammates other than me and my co-founder being the interns. So don’t worry if you got no budget, we neither. 😅
Step 1: Define a goal and a Key research question
Many people forget that ‘UX research’ is still a research, just like those you did in college for a project. It has research goal, hypothesis, methodologies etc.
First thing I did is to define a UX research goal for Savvy. As I have strong faith in our problem statement and value proposition (which you probably shouldn’t), I opted for a problem-oriented research approach and defined the goal as to learn how to better solve our current problem statement, which is ‘people not actually reading their saved bookmarks.’
Now the entire goal of the UX research as we defined is to ‘know better how to help people actually read their bookmarks’. We can then define a ‘key research question’ (KRQ).
One trick I used to think about the KRQ is to imagine that itis the most important question that we want to know about its answer, so important that as if all problem will go away if we figured out that answer and you product will start blowing up. So in our case, the KRQ is:
‘How to help people actually read their bookmarks?’.
Next thing you want to do is to try to decompose your KRQ into sub-questions. This makes answering the KRQ much easier. To do so, I reflected on user journey of bookmarking.
In our case, the user journey of bookmarking is:
- First, user see a resource 👀
- Second, user save the resource 🔖
- Finally, user finish the resource ✅ or end up not reading the resource 📚
And based on this journey, we can get 3 sub-questions:
- In what context, do people save a resource? 🎛️
- What nudge users to finish the resource? 👐
- What stop users from finishing the resource? 🚫
Ideally if we figured out the answer especially for question 2 and 3, we can then design a better solution based on the principle of :
- Amplify the nudge factors during people’s bookmarking process ⬆️
- Minimise the stop factors during people’s bookmarking process ⬇️
Step 2: Methodologies
Usually conducting user interview is already enough for the research, but I included also a group brainstorming workshop to demand more input from the team.
Here’s an quick overview of everything:
In the group brainstorming, what we did is we try to answer the 3 sub-key research questions on our own and generate some initial assumptions about it. It helps to kickstart discussion and most importantly, help us to write better interview questions when we talk to users.
After brainstorming, we prepared the interview questions and start to talk to users.
We recorded the Google call interview and wrote some key notes and insights ,then bring them into the final step — data exploration workshop.
In the workshop we used some classic UX research method like affinity mapping to analyse the collected insights. After the workshop we’re able to generate a new problem statement and value proposition.
Note that in the entire process we didn’t use user data of the existing app to help us as the scale of metrics is too small to be useful. You can well include them in your data exploration workshop if your product have sufficient data to analyse.
Step 3: Execute the plan — group brainstorming
We performed the group brainstorming with sticky notes.
So I firstly wrote the three sub-questions on a whiteboard, like this:
And as you can see there’s notes written ‘Sense’, ‘Mind’, ‘Feels’, ‘Environment’ below each questions. Those are some general thinking angle I made up based on these workshop to help us to think better. Of course we don’t want to stifle creativity so there’s an ‘Other’ area.
Next I arranged everyone with sticky notes and pen, and asked all of us to stick anything to the whiteboard, it could be just a key word or a full scenario.
We spent 15 minutes to write and stick without communicating much.
Then I asked everyone to walk around look at all the answers, and whenever you found something interesting, you can point it out, then everyone will pause and listen to what you think.
What happen is when someone point out a note and say why it is interesting, the person who sticked will response with what he or she was originally thinking when writing this. Then others will also comment and elaborate with new ideas.
We spent a good 30 minutes to perform this point-and-say session. Then I asked each of us to choose a favourite answer (as seen in the red ticks on the whiteboard).
Then I wrap-up the workshop and we share our initial thoughts on the KRQ. We actually generated some pretty good idea of how to help people read their bookmarks.
And the next task is to write the interview questions.
Step 4: Writing interview questions
There’s not much tips I can give on writing user interview questions since there’re lots of guide online and also it depends on different research goal. For us the research goal is clear — to learn how to help users read their bookmarks. So naturally we design our interview questions based on the 3 sub-questions (nudge, deterrence, general bookmarking behaviour).
And one thing I did is to let the interns write the questions, so they can be more engaged and absorbed into the problem we’re trying to solve. We then gave feedbacks and together refine the questions.
Step 5: The interview
There’s also not much I can say about how to do the user interview. I recommend this YC tutorials on how to interview them.
I managed to invite 11 interviewee, some of them being our friends who we think are potential users, some of them are ex-users of Savvy, and some of them are tech friends I made online. You don’t need to talk to so much users as there’s a marginal diminishing return on interview feedback since people start to repeat each other’s thoughts. In most case 6–8 interviewee is fair enough.
I split the interview equally among the team but I tried to show up in the most intern’s interview since I want the interviewee felt valued. Each of us wrote a doc on Notion for each interview and recorded some key insights.
Step 6: Data exploration workshop
After finishing our interview, we met and had a data exploration workshop.
Basically what we did is affinity mapping. If you’ve never heard of it, I hugely recommend you to watch the 3:06–6:26 of this Youtube tutorial.
I gave everyone sticky notes again (sticky notes = hallows of UX) and asked each of us to write down ‘key themes’ from the interview they did. Key themes are short key terms that the interviewee said in an interview. But I also allow us to write freely if they feel like elaborating on the notes.
After 15 minutes each of us at least got 15 pieces of notes full of key themes and interviewee quote. Then we stick them to the board and when we see some notes similar, we map them together (by sticking them together).
During mapping, when someone take away a note and stick to another, he or she will elaborate on the reason. This helps kickstart discussion on that key theme.
This is what we got after grouping the notes. After finishing mapping, the room initially went to awkward silence as I also don’t know what to do next.
Then I started to think what this ‘mapping’ means, on a symbolism perspective: other than just stacks of paper, it represents patterns of user behaviour. Each group of note stands for a certain common behaviour among a group of similar audience.
So then I ask everyone what they think each behaviour pattern can hint us the answer to our KRQ. We generated some ideas and wrote them on the white board.
It is from this discussion that we slowly realise one thing: not everyone cares about actually reading their bookmarks.
One interview question is ‘How would you describe the way you use bookmark, if not using the term ‘’bookmark’’?’, some say it’s a knowledge database and some say it’s a memory box.
And that’s where we start to rethink the problem: the way people use bookmarks are not like what we imagine; we originally thought if you saved something, you must have the intention to read it later and if you don’t do it, it’s a failed action.
But the data told us that perhaps users actually just want to store it, without any intention.
Step 7: Redefine the value proposition
Luckily from the interview, we learned more about the bookmarking behaviour of the users, so much that we start to figure out some underserved pain point of knowledge management among tech people.
Therefore we defined a value proposition:
‘The bookmark manager made for tech people.’
We noticed that tech people, especially developers all commonly read and saved a lot of online content as the internet is often the only source of knowledge. The case is more common for the Web3 industry.
Developers also have some specific workflow that other bookmark users don’t have such as labelling content with topic tags like #Python or #DevOps. And one very annoying habit for all of us is that often there’re 100+tabs opening in the same time, which means it’s impossible to save and tag them all.
That’s where we though we could build a better solution for devs to save, organise and retrieve their knowledge. And based on this new value proposition, we started to design a new product called Depths and code it out. In case you’re interested, this is the end result!
Sum-up
So to recap, the entire process from zero to pivot is:
- Determine your UX research approach
- Define a key research question
- Internal brainstorming
- User interview
- Data exploration
- Confirm new value proposition (pivot!)
All in all, UX research and talking to users are the keys to product-market fit. So if you felt lost on your product and don’t know how to pivot, talk to users first! I’d love to help if you need one more interviewee :)
I’d also like to thank all the interviewee who volunteered. Thank you so much Anson, Lap, Jonathan, Anson, Bekzat, Jimmy, Shandi, Saravana, Ella, Danny and Lidia. You guys are awesome!
P.S. Depths is now live on Product Hunt! Go show us some love :) https://www.producthunt.com/posts/depths
