Wednesday, December 09, 2009

Lessons learned as a SaaS startup product owner

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.

4 comments:

  1. Great Insight, Syed. Love your honesty and humility in approaching the Customer/Product Development Process.

    ReplyDelete
  2. Syed, you are not alone. I face the same challenges everyday. Interestingly, I found that as we accumulate experience, we increasingly know right from wrong (i.e., what we should do rather than what we are doing). What blurs this dichotomy is the seemingly unavoidable daily dive into the minutia of the day. Call me crazy, weird, or whatever but to help cope with this challenge, I’ve personally developed a “heightened” level of consciousness around what I and my team are doing. This allows me to step back before I get in too deep… The other thing I’ve done (although I’m still experimenting with it) is when I have these small epiphany’s (realizations) I make a point to write them down. More often than not, these mini “course corrections” are strategic in nature and tend to be “business” orientated. I think that says a lot about how we should spend our time and use our resources.

    Thanks for the post.
    Best Success,
    B.

    ReplyDelete
  3. Barry, it's funny you should mention that you write down your thoughts as you have them. I do the same using my iPhone (you gotta love iPhone).

    Thanks for your insights.

    ReplyDelete
  4. Syed, really nice and honest post. Liked it. I would say, its not just about software products where you need to think about the usability, look and feel and sense of rock solid, professional build. Its the number one requirement, often forgotten too easily.
    37Signals published a book on their website for free that tells time and again how to be very very picky about feature enhancements. We all know this but too often its a lesson learned in the hard way :-(
    Anyway, wish 2010 will be a fantastic year for your brain child, ScrumPad!

    ReplyDelete