"Fake it until you make it", how many times have we read this sentence?
Let's set up a compelling selling page, add it a five-dollar logo bought from a freelance designer on a specialized platform, spend dozens of bucks on ads to get some traffic to our selling page and we're good to go!
Let's wait a couple of weeks and compare this traffic with a total of hits on our "buy" or "pre-order" button.
If enough people hit this button, we know our idea is validated. The tactic has been proven for years so I was ready to apply it!
One thing troubled me though. My idea was an open source project. So people would have expected to see some source code. Was I supposed to pretend having a source code?
To me, this sounded like adding special effects to the movie and behind the scenes. I could not find any solution to this equation.
I had to come up with something else. So, I started coding.
The context around the idea
In my introduction article, I said I'd learned from my failures, that I won't build any project without asking for feedback. But, for this open source project, I had to start somewhere.
At that time, my goal was to validate the idea without having to spend months coding on a final product. To do so, I set myself a short deadline: 10 days to build a proof of concept of my idea.
This idea was pretty simple: a playground for developers who need to experiment regular expressions. Among the online free tools I'd found, most of them looked like this schema below:
I noticed that, if you're just starting with regular expressions, coming up with something can be quite difficult.
As you can see, if you type your regular expression in the zone n°1 and enter in zone n°2 any text such as "regexes are like mathematics: frustrating until you manage to use them", you'll see results in zone n°3. The zone n°4 shares tips to help you to build your regular expression in zone n°1.
My opinion is that, if someone needs to discover and experiment something, the tool used should be as easy as possible to understand. The sooner the benefits are perceived, the sooner they will convince.
Considering this, I applied the fact that we usually know the “what”, what we want to extract from a regular expression. The “how” remains the major issue.
This has led me to build a form where developers can define what they need and the system suggests how they might write their regular expressions. I thought it could help developers trying to get into regular expressions.
Then, I tried to validate the idea.
Ask around for early feedback
A dozen days after I started to code, my proof of concept was ready to be tested so I put it online.
Wrong first impressions can not be fixed. So, at this stage of a project, I preferred asking people I knew personally such as members of my work team, developers I had met during previous experiences or courses.
Also, I would suggest asking locally like in a meetup, in small community discussion groups around a meetup or any other event.
What I define as ideal groups are the ones big enough to get feedback and small enough to be noticed. If you notice that very few messages get responses in a group, you know it's not what you're looking for.
More important than the number of people you will solicit, you must target people that will use your project, people that might need your project.
For my project, I asked three developers that were uncomfortable with regular expressions. Having feedback from them allowed me to validate if this project, still in its proof-of-concept phase, might help them at that moment.
Also, I asked feedback in a discussion group of ~60 javascript developers, where some of them know everything about regular expressions.
Their feedback helped me to understand that my proof of concept was not covering enough regex cases. However, the feedback highlighted that this project could help to explain regular expressions to other developers.
This feedback I received validated that it could help developers learning and/or trying regular expressions. What great news that was!
Thereafter, I wanted more feedback before spending months coding on this new project.
So, I started to target outside of my network. To avoid to get the same feedback, I improved the project by adding some more common regex cases and getting the UI.
Get feedback far from your network
To share our works, there are some big players out there.
To maximize my chances to get valuable feedback, my priority was to find on which platforms developers are. As earlier in the process, I was looking for groups of discussions.
Developers are very active on twitter but I could not find groups there. Some Facebook groups and LinkedIn groups matched my size and activity requirements but I had to send requests to join them.
As for blogging platforms, to write an article seemed too much for me to get feedback.
It remained Reddit, the perfect candidate for what I needed. Since my project was written in javascript, I was interested to get feedback from javascript developers. So, I joined the subreddit r/javascript.
It's important to notice that Reddit is a place to discuss. This was convenient because my need was to get thoughts from redditors. If I needed to promote the project instead, sharing it on Reddit would have been inappropriate.
Don't show the project, ask about it
Therefore, I published a post with the following question: "I recently started to work on a playground for regexes, it is worth going further?"
Beyond asking for feedback, I included redditors in my reflexion. Not to ask permission but to know if they thought it was worth it.
As for everyone, my time is precious. If the project could not help anyone, I would not have seen any reason to go further.
Yet, I won't suggest asking if it's worth it every single time, it depends on your needs.
However, I recommend asking on Reddit because it's a perfect platform to ask and to get responses. Pick one or two subreddits where your target users are and ask about your project.
Also, note that members of the community will take the time to try your project, read your readme and give you feedback. The least you can do is to thank them. Give a response as soon as possible to all of them, from the coolest one to the meanest one.
Moreover, be ready to accept critics. They allow you to highlight what it's important to them on your project and why. Since it's very early in your project's lifecycle, it's an opportunity for you to turn these critics into valuable features.
Let's get back to my study case. The results were above my expectations. The post has been on r/javascript's first page for around 24 hours! This allowed me to get around 30 feedback!
(There are ~60 comments, half are mine because I tried to answer to everyone)
Some members of the community shared that they won't leave the tool they use such as regexr or regex101. Others shared that they would recommend it to other developers. A few of them pushed me to go further with the project!
More important than that, among the ones who understood that the project was meant for developers that do not use regular expressions, they all validated the idea.
Find a process that matches your expectations
Now, my project's message is clearer: the Regex Guide is a playground helping developers to discover regular expressions.
More than that, I now know it needs more regexes cases, a better UI, and that it will help developers learning regular expressions.
What I learned during this period is that there are many ways to validate ideas.
Earlier, I could share it with my network without code. I was just too afraid to do it and it turned out to be a more convincing project with a UI to try and a code to read.
Also, late in the process, I could have asked in other subreddits and some Discord groups to get more feedback.
The most important thing is to set a process that matches your expectations.
As a takeaway, here's a summary of my process:
– Define a target, and what main issues the project can solve (and how);
– Define yourself a short deadline to build a proof-of-concept;
– Build your proof of concept which must give a clear idea of the final product/service;
– Share it to networks;
– Collect the feedback and extract the most common of them.
This process is repeatable while clear ideas and needs are not validated.
So what's next?
My next goals for this project are to improve it, obviously, and to promote it.
I'll try to reach some milestones such as 1000 GitHub stars or a certain amount of daily visitors on the website.
Feel free to subscribe to my newsletter to be notified when I'll publish an article about it!
Thanks for reading!
Note: Need more to validate your idea? You'll find on my blog, at the end of this post, some resources to help you. These resources include a checklist of my process in the context of my project, and patterns and examples of messages to send. Feel free to take a look!
Top comments (0)