5
3 Comments

What pain points do you usually face when you're trying to find the problems that are worth solving?

I've done "build and they will come", again. I have an engineering background. I'm starting to realise that learning plethora of tech won't give me the competitive edge when I want to build something meaningful, especially in the beginning. I'm trying to approach it from a different direction this time and start a conversation about it.

So, what pain points do you usually face when you're trying to find the problems that are worth solving?

on May 20, 2020
  1. 2

    I realize when you build, there are so many different things that your mind is on technical questions and not customers' needs.

    With an engineering background it can be helped. I'm also thinking first about how can I build something before who needs help.

    This podcast with sales tips can help: https://www.indiehackers.com/podcast/119-steli-efti-of-close

    But nothing is lost, you'll be able to build faster, having refined your technical skills, but next time you'll build only what people you've talked to will ask for.

  2. 2
    1. Assuming you have picked some type of project/problem and potential customers to work on.
    2. You should start with just talking to those customers and understand their behavior around what you're working on. Don't talk solution, just understand their motivation, challenges, their -jobs to be done-, their pains and gains as an individual doing what you're working on.
    3. Understand their current options they are using now. Ask why they are not the super ideal solution for them.
    4. Brainstorm and ideate. Come with a proposition for a solution. that addresses their removes their pains, elevates their gains and performs better than their alternatives.
    5. Do not build or code anything. I repeat. Do not code anything. Resist.
    6. Create a mockup or some test experiment to validate your solution is what people would want. This could be some simple landing page just describing the product you have ideated. This could even be just an image. This could be a clickable prototype made in Invision. Be real. Don't promise thing you can't build.
    7. Test it with those potential customers. Show it to them, tell them what it's for in no more than 1-2 sentences. Don't give them clues don't ask leading questions. It will be easy to tell whether it's something that clicks with them or not.
    8. Very likely it does not make them enthusiastic about it. Then repeat at step 2 or 4.

    The executional challenges you will face while you try to do this:

    • Actually finding the right people to talk to or test with. Like literally. You need to find them, AND get them to give you time to interview them. And you need this at a constant rate. This is hard and time-consuming when it needs to be free. This is the GET OUT OF THE BUILDING part in agile. The playbook tells you to literally stop people on streets to interview them.
    • Be completely objective and interview well. Read the book (or excerpt of that book for free) called The Mom's Test. When you talk to users, you will very likely have your solution in mind, do NOT pitch your solution. First step is to just completely understand them, regardless of your solution. This is very hard. Proper user interviews that are useful and not push you in the wrong direction is something that needs mastering. i.e. Don't ask someone if they like coffee. Ask them how many cups of coffee they have drank in the past week.
    • Remembering everything. Take notes of your interviews. This sounds like a no-brainer, but you'll be surprised how many people don't think that's necessary. Lazy. You gonna forget things and then you just wasted your time. Take notes of your interviews, then write down your key learnings AND what decision you're going to take based on that. And actually FOLLOW THROUGH with the data and what you've learned. The problem with this type of things, especially in the early stages, you can bend the story whatever direction you want. Don't fool yourself.
    • You're gonna be demotivated while doing this. You wanna just start building instead of talking to people. Because coding and building is what you are good at and what you like to do. But if you want to be more than a great coder, let's say a product manager, you will HAVE to be great at all of this.

    Hope that helps. Good luck

    1. 1

      Thanks, a great writeup. A great book recommendation.