During my brief stint at Intuit, I liked this practice of meeting users of the product; Intuit refers to this practice as Follow-Me-Home (FMH). Nothing unusual in that. However what was unusual was that the whole team meets the end users of the product – the developer, the quality assurance person, the technical support person – everyone. Many people outside Intuit asked me if everyone met customers, were Product Managers needed? This is the same question that Product Managers of Intuit asked back in 2009 when lean was introduced (see The Lean Startup Eric Ries p248-50). Do we really need to go to the extent of asking if Product Managers are needed?
If the only work of the Product Managers is to meet customers and prescribe solutions based on the finding then it is over simplifying the job totally. A customer meeting provides qualitative feedback with sometimes a lot of noise. The noise needs to be filtered out by analysis of vast amount of quantitative data that one has accumulated. Combine this with what is happening in the business environment and goals of the product to decide what to do next. Not to forget the acumen needed to project manage the execution with cross-functional teams. The customer meeting, although important is one among other important things for a Product Manager. So next time there is a proposal for the developer to join a customer meet, heartily welcome it. It keeps you as a Product Manager on the toes and prevents you from prescribing solutions purely based on symptoms alone.
Photo credit: Victor
Not so long ago, when I was the Product Manager of a mobile application, my mandate was to make the on-boarding of users of the app seamlessly easy. This app was an enterprise solution and needed an alpha-numeric code to unlock and start using (for various valid reasons). For the end user, obtaining this secret code from their company’s IT folks was complicated and made several users install the app and never use this app. It would strike almost anyone as to why a normal (corporate) email authentication cannot be used for the purpose. To make end-users’ life easier by replacing the alphanumeric secret code with an email address, the work involved in the back-end was simply enormous. When I took the story to the Engineering Head, who was already inundated with too many things, the answer was not an expected “no”. I had every weapon in my armory to deflect a “no”. But I seem to have been outsmarted by a “Yes, but…”. I was told that there is an impending “fear” of the alphanumeric codes being shared and hence we must distribute two numbers instead – which will reduce the probability of a misuse. I was aghast at how this can solve anything I was trying to solve. I am not finishing the story and leave it to the imagination of the readers.
This is an instance of a user-story twisted to take a new avatar altogether – not achieving what it proposed to. User stories which are enormous in effort must be split. Changing the direction to reduce development time is not a solution. Split user stories – never change direction.
Beware of a “Yes, but…” more than a “No”.
Photo Credit: Calleaghn