Category Archives: Agile

5 takeaways from Nobel Laureate Md Yunis’ experience for Product Managers

One Young World 2010, Professor Muhammad Yunus shared his experience on how he created something that was so wrong by definitions but yet successful in creating positive impact on lives of thousands of his customers. He has beautifully summed up the thoughts that I believe every product manager must carry while he or she is working on conceptualizing new product or service. These are simple yet powerful points that can help you build a product with differentiation and having significant value proposition.

video courtesy: Youtube

While I am sure you will enjoy the video, I would like to sump-up some of the points;

  1. Think beyond Rules: Rules defined by conventional or well established business should mean nothing to you. Do not let your thoughts be caged within these boundaries. Treat them as mental blocks and just let them go.
  2. Think / aim Gigantic: Note what Professor suggested to CEO of ADIDAS on vision. Yes they are difficult but I always believe that having challenging vision helps you build a stronger character and better professional. So just go for it.
  3. Create your customer: Conventional banks have 97% male customer whereas grahmin bank went to women and close to 99% customers are female. Create your customer, identify who else can you sell your product or services to. If you are someone who works on Go-To-Market and target market you would appreciate the value that professor brings when he talks about his experience of having a branch in New York City.
  4. Possible vs impossible: Yes indeed the gap has narrowed down. It is equally important to unlearn as it is to learn. Some of the Don’ts of past have become Dos of present times. So maybe it’s time to rework on your basic assumptions you had while conceptualizing your product or service.
  5. It is never crowded for innovation / innovators: Well said, in fact I am of the opinion that a crowded place offers best opportunity to innovate.

@mathurabhay

Advertisements

Three questions for product manager Roger Cauvin

Roger

Product Mantra: What prioritisation technique(s) would you use at a startup where product users are both internal and external?
Roger Cauvin: Product managers should build consensus with every member of the product team (including internal users) for a focused value proposition that keeps internal users and stakeholders aligned with the needs of the target market and with the product’s positioning. This sort of product strategy consensus enables all team members to execute cooperatively and to set aside personal preferences in deference to delivering the promised value. I recommend composing a competitive mindshare map to position (determine the unique value proposition of) the product.

The team should agree to consider every product decision in terms of the extent to which it supports the unique value proposition.

Some practical ways I’ve used to build this product strategy consensus include:

* Walk the team through the competitive landscape and positioning represented in the competitive mindshare map.
* Interview prospects and share and review the interview notes with the team.
* Compose a slide deck of buyer and user personas and review them with the team.
* Compose a lean canvas and review, in particular, the “problem” and “unique value proposition” sections.
* Take every opportunity to relate product decisions, requirements, and design back to the unique value proposition.

Product Mantra: What advice do you have for a product manager in a startup who is expected to do more than just product management?
Roger Cauvin: Depending on the situation, responsibilities outside the strict product management role may represent a personal growth opportunity.

For example, I ran product at a startup that lacked the resources to hire a user experience designer. Consequently, it became my responsibility to design the user experience for an overhauled version of the product. I embraced this responsibility as an opportunity to learn user experience (UX) patterns and practice mocking up user interfaces.

Simultaneously, however, I educated the rest of the executive team on how user experience is not part of the product management skill set, and how a dedicated user experience designer would likely produce a higher quality design in a more timely fashion. They agreed and were prepared to hire a user experience designer once the budget allowed for it. (Unfortunately, our funding ran out, so we were never able to budget for it.)

Another avenue worth pursuing is to identify colleagues interested in carrying out the responsibilities and empowering them to do so. In startups, we all have to be prepared to be fluid in the roles we play to work as a team to deliver the best business outcomes. That burden shouldn’t lie exclusively on product management. At any particular time, for any particular job to be done, the team has to identify the people best suited to take on the responsibilities.

Product Mantra: How would you go about introducing lean startup techniques at a startup?
Roger Cauvin: First, compose a lean canvas for your product(s). No excuses. Just do it. It’s a quick way of being explicit about your product strategy so you can begin testing the hypotheses and iterating on them. I suggest composing it in Google Slides so that it’s accessible from all devices and simultaneously viewable and editable in real-time by all team members.

Second, make sure you are interviewing and observing prospective buyers and users on a fairly regular basis. If you can’t tap into the sales pipeline to identify prospects, think creatively about your own network of friends and professionals who could connect you to prospects that may not be on your company’s radar screen yet.

Third, identify the metrics that matter and start tracking them. You may need to work with marketing and/or sales ops to gain access to the tools you need, such as Google Analytics or Salesforce.

Fourth, instrument the product(s) to track usage. Tools such as MixPanel enable you to track not only events and page views, but also “funnels”, which are sequences of events that comprise a use case. I recommend documenting the key events to track in Google Sheets. For web-based applications, developers can implement events by inserting simple snippets of Javascript.

Finally, you can build consensus for lean startup approaches by educating the team about them and their benefits. Start with an introduction to lean startup and follow up by posting and walking through a model of lean startup concepts.

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 Management by Committee

One of the key issues that plagues a delivery team is having no Product Manager to guide the team. However, something that is more troublesome is having multiple Product Managers for a single product. This is what is sometimes referred to as “Product Management by Committee”. I am reminded of a scenario where a boat in a race had 5 people managing it and 4 people actually rowing.

Did you say “Oh, Come on..!! it can’t be that bad” ?

I personally feel that if you want to set a team up for failure, this is one of the things that you could definitely do.

Let us take a closer look at what the problems could be, with having multiple product managers.

Same goal, different priorities: Each PM tries to push his Agenda. Many times, each PM might have the same overall goal, but different priorities. They don’t want to contradict / confront each other. Often, they end up talking to some key resources in the team and pushing their items / enhancements without letting the other PMs know.

Collective knowledge or Collective confusion? There is a possibility that each PM has a different understanding to a scenario in the Product domain. For example, 2 PMs might have varying understanding of how an Insurance claim is to be handled when a car being driven by a person less than 25 years of age gets into an accident at a roundabout with a car driven by a drunk person. In such a scenario, the team would be chasing a moving target if they have to listen to both PMs.

Personality clash: PMs come in all shapes and sizes. Some are more technically oriented than others, some more forceful, some more knowledgeable and some more articulative. When you have a mix of such people providing directions, the team would be torn apart and staring straight at failure.

remix-monkeys-dance-clan-by-same-cc-by-sa-3-0

When Ted, my colleague took up the role of the Scrum Master for one such Agile team, this was one of the things that he identified as a failure factor. He set up a meeting with all 4 Product Managers and told them that henceforth the team would be happy to take inputs from all of them, however, all decisions and directions only from one of them. The PM committee now had to decide who that would be. They nominated Dave ( one of the key stakeholders within the PM committee) to be that person for the duration of the current release. This meant that

  • Dave would set priorities for the team and define the Acceptance criteria for each story.
  • Dave would resolve any conflict of ideas within the PM committee and provide direction to the Delivery team.
  • The Delivery team is not faced with various personalities with different agendas providing conflicting requirements. The team and PM have an opportunity to understand each other well and compliment each other for a successful delivery.

The team is now slowly increasing their iteration velocity, meeting most iteration commitments, gaining the trust of senior management and is able to enjoy their work. I believe this change has been the major factor in causing this turnaround.

Let us know what you think…

@SampathPrahalad

(Pic: Thanks to Remix Monkeys (A new creative look and Style on Urban Dance))

A healthy product development process

Below are some of the characteristics that are important for a healthy product development process:
  • Adaptability
    A good product development process is adaptive. The basis for this is users often don’t have a clear understanding what he/she wants until given something tangible. Once presented with a something tangible, we can learn which elements are useful and which are not. It is impossible to guess which elements are the most valuable. We learn from users actually using the system and ideally should be able to apply this learning quickly.Adaptability is not easy especially when executives and business desire predictability. This is especially so in large organizations as every department is expected to working according a plan. Predictability and adaptability are at odds with each other.  Predictive processes measure success by conformance to a plan; adaptive processes measure success using various customer feedback mechanisms.
    • Ability to deliver fast
      The ability to deliver fast is one of the key principles of lean product development.
      “Think of reliable, repeatable, rapid delivery as a sign of excellence in a software development organization.” Mary Poppendieck
      Fast delivery is sign of good, solid engineering practices and a mature software development organization. Examples of practices that enable fast delivery:
      –       immediate clarification of requirements
      –       no time-consuming handoffs
      –       minimal delays in testing, integration
      –       daily builds and rapid feedback from integration tests
      Fast delivery encourages an organization to take an experimental approach to product development; team members are encouraged to try out new ideas and learn from real user feedback instead of building a product based on assumptions.
  • Information flow
    There should be free bi-directional flow of information between the various departments within an organization and that too with minimum delays. Emphasis on  documents and passing it ‘over the wall’ is less than ideal; it contributes to waste and loss of tacit knowledge. The most effective mechanism of communication is face-to-face communication. The boundaries that exist  within organizations are often barriers to information flow and can contribute to loss of customer affinity.

Backlog Elaboration: A Win-Win Proposition

As we all know, Product Managers are responsible for maintaining the Backlog such that it reflects the demands of the market. As market dynamics change, the backlog changes too. The Agile way of constantly prioritizing the backlog and keeping the most relevant features or stories at the top are key to ensuring that the product stays competitive in today’s dynamic market.

Many times, the Product Manager and the Product Development team go into Sprint Planning without enough clarity on some features or user stories. This causes the planning meeting to go in circles Continue reading