How I started idea validation
To bring more context, here’s how the idea described in the previous article:
Being many years responsible for features, projects, and teams, I continuously faced a routine related to codebase management. So did my colleagues too.
Thinking of this, I imagined the system which reads your software code for you and presents needed information.
Presentation
The first step, illusory-obvious to me, was the need to make a high-level concept and presentation.
Being impressed by Eliyahu Goldratt’s “The Goal” book, I decided that the needed information is the information about bottlenecks, so my presentation became headed by the motto: “Codeventory — elevates bottlenecks in your code”.
I never planned to spend a lot here, yet it resulted in 20+ slides and two weeks of evenings and weekends before I’ve shown the result to my few close friends. Then I spent one more week and added more slides to make it unintendedly perfect.
Fortunately, I decided to show the presentation to my friend John, who already built a successful product. I honestly expected it to take no more than 15 minutes, yet we spent a good few hours talking. That’s because I had multiple problems to solve.
And the first thing John told me after carefully listening to the presentation — drop everything, except the smallest part of the reach feature set I had. And then sell it to more people.
I haven’t completely understood why he made such advice, yet my experience agreed that smaller scope is more likely to be launched.
That small part was about showing potentially breaking changes included in an upcoming software release. Like unexpected features, public API, or database schema changes.
I was so excited that we both understand the value, and it seems that my friend would like to use it!
The unexciting part was that I did not need to make that presentation at all. I could save weeks, and our conversation could save an hour for both of us.
I will return to this finding many times later — trust me or not, never do long presentations.
Mom test
The other friend I talked to was from a large corporation and had a solid product management background.
I expected that it would be useful for those people to understand what engineers change in the software. It was not a surprise that this guy was at a level where such details are not so important, yet he has advised reading the book called “Mom test”.
That was another precious thing I’ve got from those initial conversations. I had a strong engineering background, yet no clue in how to talk to people.
Sure, I can’t say that book of 140 pages has wholly fixed my issue. It just improved my efficiency in communication and gave me a better understanding of product development.
It also helped me understand John’s advice and finally hear what he said — talk to the people and listen to them.
An extremely valuable reading, unless you’ve done it already.
Startup school
One friend, who usually advises me on taking a university education I never had, showed me the Startup school or how they call it — SUS. Since it’s free and made by Y Combinator, where I wanted to apply in the future, it was an easy choice to make.
What I like about SUS — there seems to be no bullshit.
All information they provide is strictly about starting a business and making progress.
The other thing is quality.
Lecturers are people who built successful businesses already. And the program itself is done by those who helped to build businesses a lot.
One more benefit, apart from the information, is scheduled calls with other participants. Here you are supposed to practice with the story of what you are doing. And, interestingly, the matching system usually connects people from different domains and corresponding backgrounds. So you do “mom test” continuously, which is refreshing.
Some time ago, I thought if I make a product for software engineers, I will talk to engineers. So this practice introduced by the Startup School was a bit unclear to me.
Once I started talking to engineers, I realized that there are no engineers. First, there are people. Second, people might not understand you, and high-likely they will. Even you think you are speaking the same language.
Startup School looks to me as an incredible tool in both learning and validating ideas.
Covid 19
Talking to friends was a good starting point, yet it had two major downsides. First, it was a very limited source of users. Second, they were not users!
While I wanted to help engineers and managers, the decision and purchasing power were only in certain managers’ hands. At that time, I knew only a few of those who were relevant.
After all discussions, I’ve got mostly negative feedback, and maybe, considering that the “mom test” is failed, I had to stop here and do something else. However, my thoughts were about the different question — where to get more people to talk.
Originally I planned to expand my network through offline events, mainly engineering conferences, where I participated many times years before. And where I understood how to get attention at almost no cost.
Things changed with the pandemic started in early 2020.
Although I knew the term “user acquisition channel” already, it was the first time I realized it’s importance. And the significance of its reliability.
Having no chances to check how the offline channel works, I faced the need to look for other options.
And I continued.
The next article will tell about my experience with online channels like LinkedIn, Product Hunt, Reddit, and Twitter, and what I learned from that.
Alex Osin
Founder, Codeventory
