MARKET RESEARCH 5 - FOUR PRODUCT EVOLUTION TECHNIQUES: HOW TO EVOLVE YOUR PRODUCT FOR YOUR NICHE
Link to this article:
So you got the niche pinpointed, and you generally have the problem you’re trying to solve. Now you need to craft your product to be exactly right. To demonstrate how this is done, and how you deal with all the competing factors, we’re going to run through an example of an actual product I’ve done: ThirstyVIP.
The goal of ThirstyVIP.com was originally to be a nightlife social network. We however spent a year evolving exactly what it would do in the nightlife industry, and changed the concept several times. Here’s the progression of the different ideas:
1) Nightlife social network - this is what my client wanted
2) Nightlife SaaS b2b tool - this was my first alteration on the idea
3) Foursquare specifically for nightlife - we settled on this, but then broke it down further
4) Heavy-duty location based drinking game
5) Even more unnecessary features for Events, etc
6) Reduced concept with super simplified gaming aspect, and generally revolving around communication
7) Integration of a bar tab to keep track of your drink checkins in preparation for a future where actual transactions could be made through the app
So basically what happened is my client, Tyler Beerman, came to me and said he wanted to do something big for Nightlife. He already had a partially built but failed past prototype from another developer in hand. It was an iPhone app that basically served as a directory of what’s going on in the nightlife scene around you. He wanted to make it more social.
Keep in mind that this was just before the geo-networks like Foursquare took off. I said to myself: let’s make something that can actually make money since that’s how I’ve always rolled. I’ve always hated building products that have to become immensely popular and take on tons of funding before it can make money. I wanted to make a b2b SaaS solution we could immediately start charging a monthly fee for. So in #2 above I came through with an idea of tracking the performance of Facebook events so nightlife promoters could better optimize their campaigns, as well generally make the application an automated way of reaching out and marketing to your Facebook following. So one of the tools was a facebook event scheduler that would automatically schedule events each week so you didn’t have to do it each week. You could then track the aggregate performance of that weekly event over time. There were also tools to automate and simplify inviting people and reaching out to them, etc. We were going to charge a monthly fee for it and come out the gate with something that didn’t have the “chicken and the egg problem” and could make money immediately.
Product Evolution Technique #1
If you’re not familiar with the “chicken and the egg” scenario, the best example is a real estate site where you need sellers and buyers. Buyers don’t want to use your site if you have no sellers, and sellers don’t want to use it if you have no buyers. So you’re stuck in a tough position where your platform is useless until you get critical mass, and getting critical mass is near impossible. Where I was coming from with the #2 concept was that it didn’t need critical mass to be successful. It didn’t even need to be filled with tons of content like a video site. The technology just had to work, and it piggy-backed on the data (i.e. friends, fans, etc) that customers would already have living inside their Facebook accounts. This is Product Evolution Technique #1--i.e. eliminating the chicken and the egg problem by making a tool that services a specific group with the data they bring to the table.
Product Evolution Technique #2
After we basically finished planning this product, Tyler, my client, said he rather do something more like a Foursquare for Nightlife. So we scrapped all that and went there. In this stage, we spent a lot of time figuring out how we would be different from Foursquare. We said to ourselves, we have to be totally different if we want to compete. We experimented with tons of game dynamics. What that means is we planned a tool for bar owners/managers to create all sorts of promotions. We ended up with a multi-step and multi-path promotion creator where you could make basically an endless variety of promotions. You could make ones where earn promotions once they reach a certain status based on points. You could make virtual good promotions that you earn and have to redeem immediately. You could make virtual good promotions that the end user will be able to store in their MMORPG style treasure chest and use whenever they want. You could set dates, times, expiration dates, etc, for everything. Really, you could do a lot more. The point is we went overboard. But what we did do was explore basically every possibility of gameplay. And I think that sort of planning and imagining is key to the creation of any startup. Just make sure you don’t waste all the time and money to do this in code. We did this in layouts according to my FaceySpacey Speccing techniques. Let’s call this buch-wild exploration Product Evolution Technique #2. Basically, every startup has to go through this to earn their stripes.
Product Evolution Technique #3
After that, we went along even farther, and even added tools to incorporate events, as noted in step #5 at the top of this article. And soon enough we got to a point where we realized we were trying to do too much, but nevertheless had a huge repertoire--and ultimately a study--of all the possibilities for us. This led to the execution of Product Evolution Technique #3 where we trimmed the fat. So we removed Events, and made it so you can create only 1 type of promotion. Well, 2 types, because it had 2 variants. The bottom line is we simplified it by like 95% to just the best part.
At this point in time, we came to a final realization about what ThirstyVIP really is. We realized that this application was going to be a way to make real transactions at bars. Eventually, the app would connect to the POS (the “point of sale” computer where bartenders process your orders) and your bar tab on your phone would be the same as on the POS machine. And of course you could make the transaction through your phone when closing your tab. We realized that this was far off, but what we wanted to do was build the framework to go there. We felt it important for future investors to see our vision now, and for end users to get the picture of what ThirstyVIP was about.
What this all looked like is you could checkin to a bar, and perform drink checkins throughout your night. That was always part of the application. But now in the final stages of speccing this product, we added a fly-up screen that’s always present on every page of the application that lists all the drinks you’ve had, and the # of points they were worth, and of course the totals. The idea was that since we weren’t actually going to process transactions yet, your bar tab sum would be the total points you’ve earned. And you’d earn bonus points for closing tabs with larger totals. The bar tab also let you click back to the posts corresponding to each previous drink checkin you made, as well as one-click drink another similar drink, etc. So it was connected to the social and communication aspects too, and served multiple purposes. In short bar tab fit right in, and made you feel like you were really at a bar while using the application.
Product Evolution Technique #4
So that final addition is Product Evolution Technique #4. It can be summarized as: after you’ve done all your speccing of what you thought you wanted, don’t be afraid to come to a super realization of what you’re application is truly meant to be; and then backtrack a bit and take the time to rework into the application what’s necessary to make it happen, possibly trimming the fat from other less necessary things. We found ThirstyVIP’s purpose at this point in time and what it was all about. We were able to do so because we explored and examined so many possibly paths the application could take. We did so in a lot less time than it would have taken had we did this all in code by building useable stuff. We were unrelenting, and once we felt we really mastered the terrain, we zeroed in on the core value proposition, and made sure to get that right, while simplifying the rest.