My takeaways from week 2 of trying to validate my idea

So last week I made a post about what I learnt from my first week of attempting to validate Visual Backend, and you guys seemed to enjoy that, so I'm going to continue with what I learnt from my second week. Spoiler: it didn't go as well! But anyways, let's get straight into it.

What did I do this week?

This week, I mainly focused on one to one outreach since I learnt from week 1 that this type of interaction gave higher quality information. As such, I aimed to message 10 developers on LinkedIn every week. Since this is the only thing I did, I'll explain the process I used in more depth.

1. How I find people to message

I have the Sales Navigator account on LinkedIn, which I can't recommend enough to anyone who is doing serious cold messaging on the platform. If, however, you are simply testing the waters, you can send a 300 character length message to randoms along with a connection request on a free account (which should be good enough as a start). Anyways, my product is a tool for developers, so I would search up keywords like "full stack", or "node", and then filter according to job title and length of experience.

2. My approach to cold messaging

This week, I wanted to test 2 different approaches. One leaning more towards information gathering, and the other towards getting people to try out my product. As such, I had 2 message templates for each goal, and from my list of 10 leads everyday, I would send half the first template and the other half the second.

Overall, this week's validation process didn't go as well as the first week. I barely received any replies (about 3 in total) and the information I got was not very helpful, but on the bright side, that means more learning! So let's dive into why I think it turned out this way.

What did I learn?

1. Try to think of a specific use case where your problem is felt the most

When I messaged people on LinkedIn, I would ask them if they "found backend development repetitive". But "repetition" is a really broad term and seen in all shapes and forms. People have all sorts of takes on the problem: some like to use no code tools, others opt for generators, while some even enjoy the challenge of braving through a project from scratch. This meant that I couldn't extract meaningful information because everyone was thinking about the problem in different contexts!

Basically, narrow down your problem to a specific situation and start there. That way, your information will be more focused and it'll be easier to make sense of it.

2. Target a specific niche, and when you think you've gotten one, try to go even more specific

The next mistake I made was targeting too wide of an audience. In my mind, I simply wanted to talk to "developers". At first glance, this may seem like a niche, but there are so many different types of developers: indie, full-time, etc. As such, the information I was getting seemed to be very misaligned and all over the place. So combine this with the earlier point and you can imagine how terrible my learning about the problem was!

A simple task I gave myself (that you can possibly follow) is to define a unique use case for a specific niche that my product can help improve. In my case, I've decided that Visual Backend can help indie developers (niche) ship their ideas faster and validate them more quickly (use case). I look forward to testing it out this week!

3. Stop steering the direction of conversations in your favour

When talking to leads this week, I realised that I'd involuntarily try to fish for answers that would validate my idea, and as a result, I wasted several potential conversations! I must admit that this one is really hard. I've been told by countless books not to fall into this grave trap, but still unconsciously did so.

From now on, I'm going to try and keep the questions as vague as possible, and stop giving "examples" when trying to explain or ask about the problem. Everyone repeat to yourselves "let them do the talking" 3x before each interview!

---

So that pretty much sums up my validation process and takeaways from this week. I look forward to correcting the mistakes I made in week 2 and trying out new strategies to learn deeply about the problem I'm trying to solve, so that I build a product people want! In fact, I've just started twitter to build a network and test out new validation strategies, so connect with me here!

As usual, I'd love to hear your thoughts or feedback on what I've done, and suggestions for improving my validation process. Cheers!