Category Archives: Product Marketing

Michelle L. Harper @ ‘The Three Questions for Product Manager’

Michelle L. Harper

Michelle is a Senior product management and product marketing leader with a proven record of accomplishments in leading and implementing product management programs in diverse organizations to create, develop and position successful award winning products. Continue reading

Moving from Free to Paid: 3 things that you cannot afford to mess

Often consumer online products need a critical mass of users to even know if the product is indeed 6280507539_f32a72be10_qworking and adds value to the users. Most products start by offering the product/service free to attain critical mass and also get actively engaged users. No sooner does it gather enough engaged users, the juggernaut of “monetization” is on its way and the only model that might be feasible is the user-paid model. Most products usually have a well-thought road-map on how long the free model must continue and how to start some positive cash flow. When you move to a paid model, you could mess up totally by doing these:

Convolute the user experience: This strategy only spells doom for the product. Alternatively, look at features you can carve out for paid users; the user experience of the product as a whole should be left in-tact. Sometimes it so happens that the whole set of existing features forms the perfect user experience and removal of any feature cripples the product so much so that it becomes useless. In such cases, the challenge would be to create new feature set – which are enticing enough for a segment of users to pay or create a limited time period for usage of the free product.

– Delay moving away from free: The conversion percentage from paid to free is usually a small fraction; running free version for a long period increases the cost of acquisition of paid users.

– Asking for “long-term” commitment: Users moving from free to paid should have a smooth “on-boarding” experience. Mandatory long period sign-ups (even if there is opt-out facility) causes high drop-out rates among users.

You build your user base with a lot of effort – let it not wither away when you need them the most.

 

Photo credit: https://www.flickr.com/people/68751915@N05/

Banish long Sprint Planning meetings

In the Agile world, a Sprint Planning meeting would typically have the Business / Product Owner listing and explaining each story to be delivered and the team goes about doing their best to understand each story based on questions and discussions. The team then estimate the effort needed for each story and commit to whatever they think is feasible within the Sprint duration. For a 2 week Sprint, this typically takes around 3-4 hours.

In many cases, discussions on stories unearth scenarios that need further Analysis by the Product Owner before they can be ready for development. These stories cannot be picked up for development even if they are of highest priority since there are some unknowns about them. This means that the Sprint backlog could consist of stories that are not of highest priority. Also, this results in a long Planning meeting due to more discussions and more stories to discuss.

Is there a way to change this and ensure that the Sprint backlog is filled with stories of highest priority and value? Also, is it possible to have a shorter planning meeting?

Fortunately, the answer is Yes…

The key is to remove the discussions and visit all possible scenarios up front.

The answer is to have an Elaboration session for the next Sprint in the middle of the current Sprint. The Scrum Master gets the team and the Product Owner together for the Elaboration session. Here, the Product Owner presents the stories for development in the next Sprint and solicits questions and feedback. The team and Product owner discuss all possible scenarios and get a complete understanding. There is a huge possibility that some stories might not be ready for development. The Product Owner then has the time to action these before the actual Sprint planning meeting a week later.

This way, the team is fully aware of the stories coming up in the next Planning meeting, the Product owner has time to fine tune his high priority stories and many stories can be committed to and taken up for development without much discussion at the planning meeting. All this leads to a short planning meeting and a less stressed out team. The additional meeting that is added would provide value by unearthing issues up front thus providing enough time for resolution.

I strongly encourage management and teams to try this option out. Do let us know how this worked for you.

Hey Product Manager, is your backlog mature?

As the world embraces the Agile methodologies with gusto, it is important to get certain elements right to ensure that the key Agile principles are properly implemented. One such element is Transparency. A mature Product Backlog goes a long way in ensuring transparency.

For the beginner, a Product Backlog is a wish list of features or enhancements that would make your product great. It contains User stories which are features or enhancements written in the language of the end user. Contrary to Waterfall projects which have a baselined and frozen list of requirements, the Product Backlog is kept alive and constantly modified through the life of the Product. It is this changing nature of the Product Backlog that is both an asset and a potential liability. It is important to ensure that the Product Backlog does not become just a stale document of EVERYTHING that might or might not get implemented in the product’s lifetime. It is the Product Manager’s responsibility to maintain a mature backlog and once done, everyone involved in the organization stands to gain from it.

3086708145_5ed56e5e5f

With this background, I shall now attempt to define the characteristics of “A Mature Product Backlog”.

Valuable User Stories: A Mature Product Backlog contains user stories that deliver value to the customer. Each user story should take the product one step closer to the product that the end user desires. Additionally, each user story should have Acceptance criteria clearly listing the boundary conditions, performance criteria and other quality expectations.

Prioritized Backlog: The Product Backlog should be prioritized by the Product Owner in terms of the highest value stories at the top of the list. Another factor to be considered is the Risk involved in implementing the user story. It is a good idea to categorize user stories on Value and Risk and then prioritize the backlog on Value first and Risk next. High Value Low Risk stories would be at the top with the Low Value High Risk stories at the bottom.

INVEST(ed) User stories: A mature Product Backlog has user stories that follow Bill wake’s Independant, Negotiable, Valuable, Estimable, Sized appropriately and Testable (INVEST) mnemonic.

A definite list: The backlog is a list of user stories that will make your product great and it is not possible to only have a certain number of user stories in it. However, instead of having an endless list of small and big features, all I want you to do is a) Keep features that are due to be implemented in the current Release very detailed, b) Group similar features that are part of future releases into Epics and c) Keep user stories from future releases big and break them down into smaller user stories only as you come close to implementing them.

Estimated User stories: This is an Optional requirement for a mature Backlog. It is great to have a Product Backlog with user stories that are assigned story points to determine the size and effort involved. This helps the Product Owner in prioritizing the user stories. For estimating a large number of user stories, Planning poker could be ineffective and the Affinity estimating technique will be a better method.

Over to you now. do let us know if something is missing in this list.

(Pic: Thanks to Flickr: Creative Commons for the Backlog pic)

Simplicity is the ultimate sophistication

I had to drop a cheque to credit to my account; these days regardless of the value of the cheque you can drop them into the cheque drop box and usually the money gets credited to your account in a few days. The problem is when you have a high value cheque and the palpitations are high until the money gets credited – just because you are paranoid about not handing over the cheque to a teller at the bank counter. I headed to ICICI Bank to deposit my cheque and see this drop box

icici

Continue reading

Technology: Aids the experience or robs you of it?

Technology aids you and it sometimes overwhelms you. But, have you faced a situation where it robbed you of an experience?? Here is my case in point.

The use of a Digital camera: Helps me to capture moments that can be re-lived many times in later days. I have looked back at pics of family and friends that I took years ago and felt nostalgic about the moments. I am a keen photo enthusiast and love to use a digital camera whenever possible. However, I have at times felt that it has robbed me of experiencing an event as it happens. I recently went to the Sea World at San Antonio where the famous Shamu whale show is held. Me and my 6 year old kid were very excited at the beginning of the show. However, I had thrust upon myself the additional responsibility of capturing pics of the killer whales in action using a digital camera. What happened over the next 20 mins is something that most digital camera users would have experienced. My kid completely enjoyed the experience where the whales were performing various acrobatics and jumping in and out of the water with great precision. Me, on the other hand was trying hard to predict the whale’s next move, pinpoint the exact location of the move in the big pool and point my camera at the right place. And I was usually wrong.. So, by the time I turned around and pointed the camera and clicked, the whale was done with its flawless acrobatic movement and was back in the water. What I was left with was a picture of the turbulence in the water. See some pics below.

ShamuShow2ShamuShow3

Continue reading