Listening to Users in the Korean Startup Ecosystem
How to build a great product by applying the Design Thinking process to your startup
The other day a friend approached me with a product that they had built and asked me to give feedback.
At first glance, it looked impressive with cool interactions and visuals. But as I was using it, I got confused and I wondered — “What is this for?” I didn’t understand what the purpose of the product was.
Over 70% of all Korean startups only last a year. According to Korea Startup Index 2018, 60.2% of startups responded having “Difficulty procuring funding from investors, such as VC firms and angel investors”; while 28.2% identified “Lack of markets for products and services launched by startups” as the factor for their failure — resulting in building a product that no one wants.
Having spoken to entrepreneurs and startup employees here in South Korea, I keep hearing the same stories — a product or feature idea is developed without talking or testing with users, and there is no will to pivot or cut the project short.
It doesn’t have to be this way.
This article is aimed for anyone in or interested in the Korean startup ecosystem. I hope that members of this community — whether you are a founder, designer, or developer — can take learnings from my experience and apply it to your organisation.
I had my own experience at a startup where this was happening. Before I joined, all of the product feature ideas were born out of assumptions and gut feeling. This was especially detrimental as we spent so much time and resources on development that eventually ate away our runway.
Introducing Design Thinking
As a result, here are some steps I’ve taken, along with things that I wish I had done differently against the Design Thinking process. This human-centred process can be used by anyone to understand the user, challenge assumptions and redefine the problem to identify new solutions.
The Design Thinking process occurs in 5 steps:
1) Empathise
2) Define
3) Ideate
4) Prototype
5) Test
Empathise — Getting to Terms with Your Users
Working in a startup, we didn’t have a lot of budget to spend for invite participants in for 1-hour interviews. In the end, I had 15 phone calls lasting around 1 hour each where we talked about their experiences — and all for free!
Talking to people doesn’t have to be expensive. You can reach out to your personal and colleague’s networks that are your target audience or go to events/meetups that might interest your potential users. Once you make those initial connections, ask them if they would be interested in helping you out with a phone call or a coffee to discuss their experiences. Find out what motivates them, what pain points they experience and the needs in your industry.
Define — Specify your Audience and Problem
After all of the listening and learning from talking to people, it’s time to capture those stories. It wasn’t just for me to understand their motivations, needs and pain points but to help the rest of the company empathise and understand who they are making the product for.
I used two different outputs to share these stories.
- User personas that were created to give a representation of the different clusters of users — with their different motivations behind learning languages and resources they typically use.
- Jobs To Be Done (JTBD) statements that were used to outline common needs and pain points experienced across the different personas.
It isn’t just enough to create outputs. Make sure to present to everyone and keep referring back to these personas and JTBD statements during meetings — so that others would start adopting the same way of thinking.
Print the personas and JTBD statements out so that everyone is reminded each day to keep thinking about the user throughout your discussions. These learnings can impact not just on the product, but also on marketing, content strategies.
Ideate — Sketch, sketch, sketch
Had we known about design sprints at the time, this would’ve been the perfect time to start ideating as a team. However, our ideation took place over several weeks.
Without being forced, we had unprompted conversations amongst team members about the research findings during lunch and post-work beers and started sharing our own experiences and expertise about how to solve the problems that were identified. Eventually, these conversations became more alive as we started to discuss how we could each contribute to creating a new feature.
Knowing what I know now about design thinking and design sprints, I would’ve gathered the whole team to go through the research findings and start ideating by using Crazy 8s (also known as Design Studio). This is a method for a group of people to generate ideas quickly. sketching their concepts, whilst everyone critiques other people’s sketches.
This would’ve taken us a couple of hours rather than weeks to refine a concept, get diverse perspectives and collaboratively refine a concept based on everyone’s feedback.
Prototype and Test — Fake it Until it’s Made It
This is the step where I wish we had taken a completely different approach. We spent months simply building an MVP to understand technical feasibility and to collect data, which subsequently cost us resource and time.
Consider using the below approaches before building an MVP:
- Prototype and mimic the experience of the MVP without building it. This can be done through a clickable prototype or anything that mimics the experience! For example, if the feature is a chatbot interface. use Slack or Google chat to test the experience. This is great for getting early feedback from users.
- Smoke test with a simple landing page: A smoke test is a method for determining if there is sufficient customer demand for a product or service to justify building it. Typically, smoke testing involves creating a single-page website describing the product/service, prompting visitors to sign up or register for this phantom ‘product’, in the belief that the product is available or in development. It is great for gaging appetite for a feature idea, whilst mitigating the risk of its launch.
These two approaches help to mitigate the risks and to make any refinements for the product before you create an MVP.
To Conclude
Before this, the product roadmap focused on building a feature born out of gut feeling. But now with the research, we were able to shift our focus to a feature that was born out of user needs. It meant that we didn’t waste our time and resources building the wrong features. A feature born out of research also led to a partnership with a Korean conglomerate.
Considering that Korean startups have a problem with funding and lack of product-market fit, initial research will help you along massively to save time and resources, and most importantly to build a product that solves a problem!
Many individuals and organisations jump to think about the solution first, and I plead to you to identify the problem first using the design thinking process. Take the time to get to know the people you are building for :)
For Your Commute Read
In addition to the above tips, check out the below for more information about the Design Thinking Process:
- A more detailed description of the 5 stages in the Design Thinking Process
- Online course to learn about Design Thinking Process
- How to introduce Design Thinking into your organisations
