It's been almost 2 years since we (Code71) embarked on a journey of building a SaaS product called ScrumPad. I have been playing the role of a product owner (PO). Although I have played the PO role on projects/products for our customers, being a PO of your own product is quite different. I thought it would be good to take some time and jot down my experiences so far. So, here it goes:
Minimum viable product (MVP). Initially I did not really think in terms of let's build an MVP and put it out there for feedback & iterate. We took on this initiative to meet our needs based on our dissatisfaction with the choices available in the market at the time. So, I gave a free reign to my team to build out features. We were stung by that "SNT" bug as Dharmesh puts it. The results was, you guessed it, a sprawling a set of features. When we realized that we had piled on too many features too quick, it took us sometime to cleanup the clutter. It still is not easy, but I am getting better at restraining my and my team's enthusiasm around new features.
Usability and performance. We were focused on features rather than usability in the beginning. We thought getting the features right is more important than making them feel right. Boy, were we wrong! It hurt us more than anything else. We are still working on getting this right. I realize that this is an on-going effort. You are never done with usability and performance. In the Web 2.0 world, it is in the front and center of any product development. I now have at least one story in each sprint that focuses on usability and performance.
Brand. I thought a nice logo and a design theme can always be added later. So, I continued to put it off until when I realized lack of it is causing inconsistency in user experience. When we added a well thought out design with logo, the impact was clear. I wish we did this at the beginning. We could have saved some rework and retained some early adopters. A product without a design theme is like a boat without a radar.
Idea, Build, Product, Measure, Feedback, Learn. Yes, this is the "lean startup" cycle introduced by Eric Ries. This is Agile applied to Startups. Although we were doing Agile/Scrum even before we started working on our ScrumPad product, it was limited to only our engineering process. I came across the "lean startup" framework when I met Dave McClure and Erik Ries this September during the "Geeks on a Plane" trip to Europe. I realized what is missing from what I am doing as a PO is driving product development decisions based on the rigor of "measurement-based learning." We had a basic tracking (e.g., basic Google tracking, custom "project activity index") setup. It was not anything close to what Dave describes in his AARRR (Acquisition, Activation, Retention, Referral, and Revenue) framework for startups. Even the minimal tracking (project activity index) we put early on helped us quickly detect a potential issue we had with our initial setup process after registration. However, I always was torn between working on "a product feature" vs. "a tracking feature." Always the former would win over the later. Now, I realize it is not one or the other. They are one and the same. I need to rollout a feature along with the ability to track and measure its impact on one or more AARRR metrics.
Charging early. When we decided to open the door to our service for others, we offered it for free. It did not feel right to ask people to pay for a product that is in early development phase and not stable. I thought I would not get people to use our product and provide us "useful" feedback if I charged. The reality was quite the opposite. Yes, we saw people singing up for our service. We were excited. We were getting some feedback, but none took the time to point out what was working and what was not. So, we continued to focus on thnigs that did not matter to our users. Sure enough, when we finally thought we were ready to start charging for our service, the users fled in all directions. It was demoralizing for us, but interesting to me to experience it first-hand the importance of "charging early, and often." It took us some time to build our user base back again. This time with the fees in place, we see a stark difference in the quality of feedback. It is because now the users have a skin in the game.
What kept us alive? As you can see I made all the mistakes I can make as a first time entrepreneur PO. However, I believe we did a few things right that helped us survive our mistakes so far. First, we were putting out a new release every two weeks since we started working on ScrumPad. Second, I was able to muster up courage to stop adding new features and focus on re-factoring to get us back on track. Last but not least, I ignored the temporary inconvenience to users when we were making changes to the look and feel incrementally, even if it meant some parts of our site looked completely different from another.
Now with 2010 around the corner, I am ready to drive our product development pivoted in the lean startup concepts. I'll report back on how it is going some time next year.
Are you a PO of a startup SaaS product? I would love to compare notes. Please drop a few lines.