Category Archives: customer meeting

Tweet Theorems of Product Management

This post is going to be a lot different from what you are used to read at Product Mantra. It is not that I have ran out of ideas but this post itself is an idea that I surely wanted to experiment for quite some time now. Hope you are going to like it.

Tweet theorems are simple yet powerful message that every product manager should have on his/ her pin-board. This post is influenced by tweets from Jeff Lash, Amanda Ralph and John Cutler. Continue reading

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.

Solving the puzzle – “water proof umbrella”

In my previous post, “Case Study: The Waterproof Umbrella” I wrote about “Out of Context engineers”. Engineers who are working on product or on feature but are not sure about its usage or need. While the earlier post was focused more on challenges, this time it is more about what a product manager should do to help engineers gain contextual knowledge.

There are ways by which you as a product owner can make the out-of-context engineers have a better understanding about product.

Detail requirements along with context : Charity begins at home, so why not start with little extra effort to help engineers understand something more about the product needs. When you write requirement definition or user stories, do ensure to include sections like “feature purpose”, “problem definition”,  “Expectation (from feature on implementation)”. A typical ‘User Story’ with ‘uses cases’ is not good enough for many engineers to understand the context or need, it rather just focuses on solution space and has bare minimal focus on problem definition or customer voice. Including suggested section along with accurate data helps engineers to connect problem definition with use cases and in-turn helps in designing an effective and elegant solution.

Customer experience : It is highly recommended that engineers who mostly have cubicle working habits should be taken out to meet customers, partners and field staff. When you go out to meet customers for a presentation or for a follow-up meeting, take one of these champs along with you. Let them have customer exposure, understand the expectation from horse’s mouth and feel the context. What is being suggested here is not something new but is definitely something which is not practiced so popularly; successful product companies like Intuit does practice this which is termed as “Follow Me Home”. You will also find a reference of this in “Lean Start-up” by Eric Ries. What this does is that it brings in a lot of contextual information to engineers, helps them understand that the customer focus is more on solving a problem and not necessary developing a feature as mostly perceived by engineers.

On many occasions, there are business or legal constraints due to which it is not possible to take an engineer along with you. For such scenarios, ensure that you share experience from customer meeting with the team and help team come to same level of understanding as you are.

Market updates : Send out updates in form of write-ups, ppts or even as a small talk once in a while to engineering team on what’s happening in market place, what is competition doing, newer announcements by government or by compliance agencies which could probably impact a feature or aspect of your product design. You chose the frequency, but ensure do not over-do or be so rare that engineers lose interest in such updates. This is an attempt to keep engineers connected with market place and also help them understand the business aspects of the product. They will sooner or later appreciate such information and also its implication on feature design or product road-map.

It is always advisable to have someone in the team who can challenge your understanding, only to help develop a better product and a better professional out of you. I take this as part of product manager’s responsibility to keep his team connected with the market and in turn with customer. Spend some extra time to detail out things that you might not have been doing, spend some time educating your team to ramp-up their understanding about business and problem you are trying to solve.

@mathurabhay

Product Manager as Sales enabler

One of the many key roles of a Product Manager is that of a ‘Sales enabler’. This means, helping sales to improvise on conversion ratio, conversion of a prospect to a paying customer. While there is nothing much that a product manager can teach sales about sales, however they can play a crucial role in influencing customer and by helping them in build trust and confidence in product sold to them.

Think of a product manager as a walking & talking “Sales-Solution-Guide”, may be something like a breathing wikipedia of the product. Sales should be able to take them to all potential large customers or even to an existing key customer.  Here product managers takes on greater responsibility of market success and such a shift typically happens largely in introduction and growth phase of the product wherein quick conversion is imperative to the success of the organization.

Here are few value adds that a product owner should focus on while working with sales or running a product demo with customer; remember it is product managers responsibility to be valued and not to be seen as liability:

  1. Know your product, functions and technicalities. Have a very good command of your product features and intricacies of user experience. It would not leave a good impression on customer if you repeat this too often ‘I shall get back to you on this’.
  2. Highlight customer benefits against each feature demonstrated, ensure you speak more of customer interest, few examples: how a particular feature impacts staff productivity or data security. May be even on reliability of data.
  3. Aspects that can be translated to monetary benefit like increase in top line or bottom line should be explained thoroughly. Question audience if they have any doubts over monitory benefits of the product. Typical example: lower cost of ownership for customer (in terms of hardware requirements and maintenance).
  4. Study competition well, as much as you can. Be prepared (or be honest) to answer questions on competition strengths and values that you are still trying to match.
  5. Customers often ask for more, more than what is offered or even required. Know well what level of customization is doable and in what time duration. It gives immense pleasure to customer when they convince a vendor for customization so please do not rob them off this pleasure, be prepared for taking some extra work for engineering.
  6. One of the most common question that I have faced is “how frequently do you upgrade your product and at what cost would we get it”. While on most occasions you will be able to pass on the question related to cost but ‘frequency of software upgrade’ is domain of product manager. You are expected to answer this but be sure that you neither exaggerate nor should you play too safe by being conservative.
  7. Towards the end, buy some time from customer to present technology road-map. Show customer the benefits of going with you, show them what they will miss if they go for alternate product or solution. This matters a lot to the customer and they expect you to present this to them.

I have always enjoyed the responsibility of ‘sales enabler’. I see this as an opportunity to meet and talk to customers whom I represent day-in and day-out in my organization. Perhaps I must say that, it is these opportunities that keeps me up-to-date with customer priorities and market demand, in-turn makes me more effective in my role as a product manager.

@mathurabhay

——

Case Study: Success was Inevitable

Some time ago, I was assigned a critical task at work. The task was to take the ownership of our new software solution for tablet devices that my company was banking big on. It was a strategic initiative that top executives was hoping high on and the company had a few prestigious customers lined up for demonstrations and piloting the product Continue reading

Case Study: Buyer is not the end-user – challenges for the Product Manager

Amol, the product manager of a Set Top Box (STB), was responding to a RFP (Request For Proposal) from a DTH (Direct To Home) operator; the contract if secured would mean significant revenue boost for 2 years, to start with. The STBs would be purchased by the operator in bulk and distributed to their customers (end-users). The RFP had a series of detailed questions on securing the digital content transfered, tamper proof ability, over the air firmware upgrades, recording capabilities – among others. Amol was as usual irritated. Continue reading

Three (un)wise monkeys

Photo by Anderson Mancini

The three wise monkeys are a pictorial maxim. Together they embody “see no evil, speak no evil, hear no evil”. Twisting this a bit to product management, one can create a perfect recipe for Product Manager moron who:

  • Refuses to see the emerging trends, competition, change in market dynamics
  • Refuses to speak to stakeholders and keep them informed
  • Refuses to listen to explicit and tacit needs of customers

When it comes to “evil” – every human must try to emulate the wise monkeys. However when we speak of “products”, Product Managers must keep their ears and eyes wide open – pretty antithetical to what the above pictorial maxim denotes.