A little while ago, we published a post about Joel Gascoigne who put up a product landing page with pricing information before he did any proof of concept work on the product itself. The idea was to see whether people would sign up for the product from just a pricing page; if so, he would continue working on the idea.
After the post we received a few emails from people who mentioned that they went as far as thinking through the business model behind their product before figuring out what the product would do. Jumping straight to a business model without first validating your product concept may prove to be a big waste of time and money. In fact, validating the concept is one of the first things we do after we conceive an idea.
At this point, we've worked with over 150 companies, and have built and launched 9 apps of our own. Many people have asked us about the process we follow when building products. Rather then emailing those people directly, we wanted to share the product development process here on the ZURBlog. We'll use one of our apps, Bounce, as an example.
1. Proof of Concept
We start with the proof of concept: Will our product idea work? The concept behind Bounce was simple: take a webpage screenshot without installing anything and provide feedback on the screenshot by adding notes and saving the post. The question we asked ourselves: Is this possible? Can we grab a screenshot from any browser without installing anything or having to log in?
We iterated through sketches, gathered feedback from internal team members, and built a quick demo of what the app would look like. This was a very rough demo, and no engineering time has been invested at this point. We were just trying to see how the app would work. We gathered a lot of feedback at this stage from our team and from friends of ZURB. It's important to note that all the team roles (engineering, marketing, product) were involved in providing feedback.
2. Working Prototype
Once our team is on the same page regarding the product concept, it's time to create a working prototype. For Bounce, the question we asked ourselves at this stage was: Will this work as a service? We spent about 1 month building a working prototype for Bounce.
3. Validation of money
As we build a working prototype, the question we begin to ponder is: Will people pay for this? This isn't the first time we thought of this question, but now is when we start to create a business strategy for the product. In the case of Bounce, it ended up being a feeder app for the mother app, Notable. In other words, we decided not to charge a fee for using Bounce, but instead charged people who wanted to upgrade to Notable in order to get more functionality such as privacy, better capturing capabilities, organization and others. After launch, Bounce quickly became the #2 referrer of traffic to Notable. We spoke about the boost Bounce gave Notable during a talk we gave at the Web 2.0 Expo.
4. Build a customer base
At this stage in the game, we have a working prototype and have validated that we'll be able to make money from this product. The next question we ask is: Can we get customers to stick with us? How can we acquire customers and keep them engaged? Building a customer base is a whole different post in itself; there are many nuances involved in acquiring new customers and keeping them engaged. We wrote a great post on customer development which illustrates some of the thinking that goes into this effort.
5. Find the formula
The last step is to find the formula that works and start investing money. The question we're asking here is: What is the magic formula here so that the money we invest into the product will produce bigger revenues? The answer to this takes years to perfect. Lots of tweaking is involved at this stage. We go over our customer development map numerous times to figure out the trigger points that drive conversion and the touch points responsible for maintaining retention. We wrote a post about driving conversions for another one of our tools a little while back.
This process is not rocket science, and it's also not the only one that exists out there. This is just one that we have used many times and the one that has worked nicely for us. A lot of things we go over in each of the sections above seem like common sense, yet we constantly see people skipping one of these steps and trying to come back to it later. Marty Zwilling wrote a post illustrating this phenomenon. We'd love to hear your comments as well as the process you follow when building product.
