Back from a blog vacation

December 7, 2009

It’s been long, real long – a blog vacation for close to an year is not good, but there wasn’t much I could do. I was however pretty active over on Twitter – my handle is @vinodhn and reasonably active on Facebook.

So what was I upto this year ? Well I was on a learning overdrive, I helped a great team bootstrap a product, complete web based product built from scratch, and took it all the way from the PRD to SEO , Marketing and PR.

So yes, the past year has been interesting, did some awesome work and met many a smart people. Learnt insights into the Indian product startup space and learnt and tackled challenges that startups face to get a product market ready.

I hope to share more detailed insights on this journey over the past year with all of you on this blog.


It gives me great pleasure to announce that I will now be guest blogging for the Product Management View – a blog focussed on product management and strategy , run by world class product managers from various backgrounds and vast experience in this field.I am pleased to be associated with them and look forward to some great discussions over there. Thanks to Stewart Rogers from PM view for making this happen.

My first post for the Product management view is about maximizing product value through effective feature prioritization. Looking forward to hearing your thoughts on this topic and having some great conversations.

The PM view also tracks major webinars on product management, you can sign up for a webinar remider service and here’s the handle to the RSS feed.

The slide deck below from Sequoia Capital is some solid advice about dealing with the entire economic crisis and recession from a startup standpoint. If you are an entrepreneur in any part of the world, I am sure there’s something useful for you in this deck.

In fact, the slides below give a good synopsis of the entire problem in the US and global markets and the effects which they have had on the global economy and how startups need to deal with new challenges and realities. I especially like slides 46-55, which are strategies which startups can adopt to get past the tough times.

What do you think ? If you run your own startup, what’s your strategy in dealing with the tough times ?

With more and more web products hitting the market everyday, the importance of delivering value to end users through your product has become paramount.

If you are building a product from scratch, prioritization of features becomes the most critical task and this can determine success or failure for your product. Most of us product managers love to add features – customizable user interfaces, changing password, RSS feeds etc. Faced with such a situation, here are questions that I usually like to ask myself

  • Is your feature solving a particular problem of your user segment ?
  • Is the feature adding value to the way your end users solve their problem ?
  • Is feature increasing usability or improving the user experience in the product?
  • Is the feature cracking a technology problem which others have failed to solve ?

Prioritizing features can be quite a daunting task for your entire product team – from product managers to technical architects keeping in mind that you still need to build a great v1.0 and hit the market within time and budget.

Many product companies, especially startups have failed because of this critical reason. 37signals’ Getting real is a great read to understand the dynamics involved in building web products.

So is there any best way to solve the prioritization problem ? Well, there’s a technique that I have been using, some parts inspired from here.

It’s a simple four quandrant technique with two axeses

  • Difficulty of implementation on the X axis – This indicates the time, effort, cost and technology complexity of implementation a particular feature. This ranges from low to high
  • Business Value on the Y axis – This indicates the business value of the feature in terms of revenue, greater user adopting, cost savings etc.

Get your entire product team involved in this exercise, first starting out with a list of all possible features which you can build into the product. Then get the product management/business team to evaluate all the proposed features on their business value. Get the technical team to evaluate the difficulty of implementing each of the features.

Then map the features into the four quadrants as shown above.

  • High business value, Low difficulty level- These are what I call the “Cash cows”. These are features that you would definitely include in your product as they bring maximum value with least effort. No brainer!
  • High business value, High difficulty level – This is the tricky part. These might be your niche features, or features which separate your product from the rest in the segment. These features are strategic investments that you might need to make for the success of your product. Rethink about each of these features and how they can potentially be simplified to move them to the left. Also evaluate features from this category which you want in V1 and push some for V2.
  • Low business value, low difficulty level – These features are straightforward abilities which are present in most of your competing products. Make sure that you don’t add all these features into your product to avoid feature bloat. Think about how you can potentially make simple changes and move them up the value chain. Think about whether these can be monetized in any way and check if you can change the way these features have been implemented by your competitors.
  • Low business value, high difficulty level – These are features that you want to stay away from as they provide very less value.

So, what do you think about the effectiveness of this method ? Let me know the techniques that you have for prioritizing features.

Update: A great read from the Silicon Valley Product Group (SVPG) blog on the similar topic and tips for product mangers : Great Products by Design

Microsoft is finally into the agile bandwagon. They recently announced the eScrum tool.

eScrum is a Web-based, end-to-end project management tool for Scrum built on the Microsoft Visual Studio Team Foundation Server platform. It provides multiple ways to interact with your Scrum project: eScrum Web-based UI, Team Explorer, and Excel or Project, via Team Foundation Office Integration. In addition, it provides a single place for all Scrum artifacts such as product backlog, sprint backlog, task management, retrospective, and reports with built-in context sensitive help.

This was a tool which Microsoft has apparently been using internally, they put it up on the web on June 12, so looks like they want to get feedback from users and then commercialize it.

Here are some screenshots.




References for agile

June 11, 2007

In continuation to my previous post, I got requests from friends to learn more on agile and for good references on agile on the net. So here goes.

  1. Martin Fowler’s blog – Of course, this is my favorite and I have loved reading Martin’s blog which is very informative but at the same time very simple and easily understandable by any one.
  2. Wikipedia – The best place to start if you have no clue on agile. 🙂
  3. The agile alliance web site.

The following are a collection of good books which have been suggested by people in no particular oder.

Following books are found to be good by many readers

1. Agile and Iterative Development a managers guide by Craig Larman
2. Agile Project Management by Ken Schwaber
3. Refactoring by Martin Fowler
4. Working with legacy code by Michael Feathers
5. Agile Estimation and planning by Mike Cohn
6. Agile Project Management by Jim Highsmith
7. Crystal Clear by Alistair Cockburn

If you think that a good book can be added to the list, drop a comment.

Hope this helps.

Having worked on a couple of projects on agile, and a distributed agile between the client’s team and our team, I have started liking this approach and really appreciate the fact that it can provide really great bsuiness value to the customer especially in terms of being able to tackle changing requirements.

The following are some of the reasons how agile made life really easy for our team and why I think it changed the way we worked and looked at the process of building a product using the agile methodology.

  • Continuous integration using CruiseControl which avoided last minute integration issues.
  • Doing daily status calls and stand up meetings, which ensured that everyone in the team knows what’s going on and enabling a PM/PL to know the current status of the project at any point of time.
  • Creating sprint backlogs and burndown charts – which enabled the team to focus on the tasks ahead for the week
  • Iteration planning which enables to prioritize the features that are needed in every iteration.
  • Using a collaborative platform like wikis/portals where all the relevant information is present at a one glance and any one joining the team newly had very less ramp up time.
  • We also found that having some people from our team to work out from the client’s loaction in order to make communication easier and for us to understand the client’s working environment better.
  • Having builds on a daily basis enabled us to get quick and frequent feedback from the client and this enabled us to deliver the best possible product to matc h the client’s requirements.

Overall, I think it was a reallly good experience working on agile, and the best part was doing it distributed between the client and our team, as this increases complexity and brings in more challenges.