Featured

Writing High Impact Idea/Opportunity Narratives

Opportunity identification and ideation are two most exciting aspects of Product Management. The impact of a Product Manager can be measured by how they maximize the value of the investment towards an idea/opportunity.

Every idea needs to be backed by data. However; it is not uncommon for Product Managers to arrive at a idea or solution based on intuition and gut feel. The question that needs to be asked in such scenarios is, how can Product Management leaders ensure they do the due diligence before throwing the idea over the fence for implementation? In most cases, the level of analysis done in support of an idea or opportunity is inversely proportional to the level at which the idea is conceived. In some cases, ideas are biased based on how higher up in the hierarchy they are conceived. The problem worsens when a product leader starts to react to customer needs and market signals causing constant shift in the strategy and decisions. This is where idea/opportunity narrative can be helpful.

Why write idea/opportunity narratives?

Narrative writing is a holistic approach to idea/opportunity definition. A narrative paints a vivid picture of how the product can improve the customer’s life or solve a problem. Each part of the narrative encourages a well thought out and evidence-based definition. Narrative writing can be looked as way to confirm or deny decisions based on instinct or experience, backed by data.

Narrative structure

An opportunity/idea narrative is not a requirements document. It is a light weight (a one to two pages document), focused on answering the following questions in as few words as possible. The structures provided below are for guidance purpose only. What is important is to understand the intent behind each section and find whatever structure suits you the best. Let’s look at different questions one needs to answer for a complete and effective narrative.

Customer problem

Looking at a problem from the eyes of the customers is the starting point. The problem can be for an external or internal customer. For example; the time taken for the customer waiting in line to check-out at a retail store during a sales event versus the number of associates a retail store needs to hire to cater to the high traffic during a sales event.

A problem can be framed using the structure below:

<Today……>

<Have to…….>

<When……>

<Which…….>

Example:

Today, customers wanting to shop at a retail store

Have to wait in long check-out lines

When shopping during a sales event

Which negatively impacts their shopping experience and sometimes forces them to abandon purchase and go to other retail stores for their shopping needs

The same problem can be written from a business perspective:

Today, brick and mortar retail stores

Have to recruit additional staff and deal with abandoned purchases

When dealing with long check-out lines during major sales events

Which negatively impacts customer experience and bottom line

Opportunity

Opportunity definition is bold yet crisp definition of the customer experience and business value with a positive connotation to the customer problem. The opportunity description should not be limiting and must encourage innovative ideation.

The opportunity may start with a “how might we…” statement. For example:

How might we eliminate the check-out process all together.

This opportunity definition can address the problem for customer and business in the retail store scenario.

Solution

This is a high-level view of the solution that provides insight into the “how” of the solution. The solution description can include the solution concept, and technology to be used. When written well, key objectives can be determined through the solution description.

The solution description can follow the below structure:

<We will…..>

<By Using….>

<So that….>

For example:

We will eliminate the need for our customers to stand in a check-out line all together.

By offering AI enabled smart carts to offer self-checkout option

So that customers don’t have to wait in line and can self-checkout in a minute or less

The solution description becomes an input to subsequent detailed solutioning discussions.

Customer impact hypothesis

This is a hypothesis about the outcomes that the idea will drive for the customers. This hypothesis is based on current data trends and the impact the solution will create in future. Customer hypothesis can follow the below structure:

<Today…>

<Resulting in….>

<With…..>

<We expect….>

Example:

Today, customers spend 12 to 25 mins waiting in the check-out line during sales events

Resulting in frustration and 8% abandonment of cards and loss of ~12% foot traffic to competition

With AI capable smart shopping cards

We expect to cut down the check-out process to less than one minute

Business impact hypothesis

Similar to customer hypothesis, business hypothesis focuses on outcomes but from a business perspective. Business hypothesis can follow a similar structure:

Example:

Today, customers spend 12 to 25 mins waiting in check-out line during sales events

Resulting in frustration and 8% abandonment of cards and loss of ~12% foot traffic to competition

With AI capable smart shopping cards

We expect to cut down the check-out process to less than one minute for the customers by November, 2023 reduce cart abandonment rate by 75% and, improve loss of customers to competition by ~60%

A narrative is deemed complete once the above-mentioned questions have been answered.

The last part of the narrative focuses on anticipating potential objections, doubts, and questions customers, and business stakeholders may have about the idea through customer and business FAQs. Some sample questions for the smart-cart idea are captured below:

Customer FAQs

· When will AI enabled smart carts be available at the stores?

· Will a mobile app be mandatory to use a smart card?

· Can I shop using a smart card without having to share my credit card information in the app?

· Will I be charged to use the smart cart?

Business FAQs

· What is the cost breakdown for each smart cart including hardware and software?

· When do we plan to recoup the investment?

· Can we offer smart-cart technology to other retailers?

· How would we know that the product is meeting business objectives and key results?

· What market research been conducted to assess the appetite for a smart cart?

· How do we know that smart-carts will solve the problem?

FAQs about narrative writing

Q. When should a narrative be written?

A. A narrative can be written as soon as a potential idea/opportunity is identified. Given ideas originate anywhere and anytime, a narrative helps assess all aspects of the idea and ensures just enough up-front analysis to confirm desirability and feasibility before any committing to it.

Q. Who writes the idea/opportunity narrative?

A. The narrative is best written by the mind conceiving the idea to reduce the cycle time to get it on paper. The higher the level conceiving the idea, the most important it becomes for the individual to write the narrative. For example; if the Chief Product Officer (CPO) has an idea, s/he should write the narrative instead of delegating it to the others. Adequate help can be solicited for any data to have a outcomes hypothesis that is based on research and data.

Q. How long should a narrative be?

A. A narrative should be 2 pages or less. This forces author to keep each section crisp and to the point. Short narratives are also helpful in establishing alignment when it comes to gathering stakeholder feedback where narratives can be shared ahead of time for discussion or read silently before any feedback is shared.

Q. Are any parts of the idea/opportunity narrative optional?

A. Not initially. I suggest following the prescribed structure till a few narratives have been written and the value of each section is understood. Once you have a better way to capture the information required, change things by all means.

Q. What are some idea/opportunity narrative anti-patterns?

A. Following are some idea/opportunity narratives writing anti-patterns:

· Narrative as an execution plan — A narrative paints a vivid picture of how the product can improve the customer’s life or solve a problem through a outcome based hypothesis. A narrative is not a promise to build or an execution plan.

· Narrative as a requirements document — A narrative is not a requirements document but is a high-level view of the idea/opportunity and solution. Once there is a decision to proceed, standard requirements process should be followed.

· Narrative to fix delivery timelines — A narrative is not a project plan with a date attached to it. A narrative should not mention a specific delivery date or timeline.

· Narrative to define objectives and outcomes — A narrative defines objectives and outcomes as a hypothesis. The hypothesis should not be taken as a promise to value delivery.

Accelerating Scrum Success with Lean Principles

Screen Shot 2018-09-28 at 1.57.58 PM

For organizations that have been on the agile journey, Scrum has been the framework of choice for some time now. The simplicity of the framework and its ability to enable the empirical process are some reasons behind scrum’s success. Having said that, one may question if teams have truly attained agility by doing Scrum.

 

The terms scrum and agile are often used interchangeably which is where the distinction between doing Scrum and becoming agile becomes important. According to me, if Scrum is the means, agility is the end. To put it simply, Scrum is like a driver’s manual. A learning driver uses it till the time he/she is internalizing the rules of driving on the road. Once done consistently over a period of time, the driver is easily able to navigate through the traffic without referencing or following the manual at each step.

From Doing Scrum to Being Agile – Impediments

Every aspect of scrum has a purpose. From the roles, artifacts to the events, there is a value associated with everything. However; it is noticeable that teams that have been doing Scrum for a long time have not always shown behaviors or patterns of a high performing team. This points to the issue of scrum being adopted as a process without the end in mind. It has been validated the time and again during my engagements with organizations that have been doing scrum for years.
Agile is consistently referred to as a mindset based on the values outlined in the agile manifesto combined with the agile principles. However; teams struggle to successfully attain the mindset shift for the reasons mentioned below:
  • Training(s) – Most agile adoption initiatives start with trainings which are intended to familiarize teams with Scrum framework with limited focus on the agile mindset. Yes, the agile manifesto and principles are covered but there is not enough focus on educating the teams on how they can graduate from doing scrum to attain agility. This often leads the team(s) to believe that Scrum is the end state.
  • Scrum as a process – Once a team has been trained, the next step is to ensure adherence to the framework. Generally team will have a Scrum Master whose job is to promote and support Scrum as defined in the scrum guide. Interestingly, while some organizations look at their Scrum Masters as coaches, the scrum guide does not associate the term “continuous improvement” with the Scrum Master role. This also makes the teams assume scrum as a process and end state.
  • Process compliance – Organizations with multiple teams often enforce compliance which is attributed to the need for consistency  of process and the usage of supporting tools like Jira or Rally. This idea of compliance is generally directly in conflict with the attributes of self organizing and self managing teams forcing the teams to live in the scrum box.

Above mentioned are just some of the reasons. You might have your own but the focus is to emphasize the need to go beyond the process.

Applying Lean Principles

Source AK IT-ConsultingThere is knowledge base that connects the roots of Agile to Lean. Lean got its start from manufacturing and applying it to knowledge work required a mindset shift. Lean introduces a customer oriented flexible system for software development. Applying lean principles with scrum teams have shown some encouraging results.

In their book, Lean Software Development: An Agile Toolkit, Mary and Tom Poppendieck outlined how these Lean principles can be applied to software development. In the most simplistic form, these lean principles can be applied on top of scrum the accelerate the move from doing scrum to being agile.

Lean and agile be definition are different things but they are great partners intended to achieve common outcomes. Here is how lean principles can be applied to further mature scrum teams:

Screen Shot 2018-10-03 at 9.22.53 AM

Eliminate Waste – A variety of wastes impact the outcomes of scrum teams. In large organizations, these wastes are commonly attributed to processes, complexity, structures, silos, hierarchies etc..  Organizations and teams that are relentless about continuous improvement can benefit greatly from consciously and incrementally looking for opportunities to eliminate waste. Value stream mapping should be conducted at the business and development process level to expose waste and create urgency to eliminate them.

Build Quality In – One of the common struggles for scrum teams is to deliver the “potentially shippable” artifact. Reasons include quality of requirements, structure of requirements (not vertically sliced), dependencies, unstable environment, team silos, processes, handoffs, metrics and more. However; the most common reason is the number of defects produced in sprint or the lack of tools and/or automation to support end to end testing and the mindset of dealing with defects.

Taiichi Ohno when talking about the Toyota Production System talks about jidoka (self-regulation). The idea came from a loom which would stop automatically when a thread broke. When applied to software development, the idea is to enforce behaviors of urgency, collaboration, swarming etc.. as soon a defect is found.

Additionally, the lean principle of building quality in starts by suggesting that quality if everyone’s job and not just QA’s and it needs to be a disciplined practice. Lack of it also is in conflict with the first principles of eliminating waste.

Create Knowledge – This is referred to as “Amplifying Learning” in Mary and Tom’s book where the best way of learning something is by doing it or in other words by actually creating value. Lean is also about learning through experiments. These behaviors and/or mindsets are not often observed with scrum teams.

Some common anti patterns that impede the principle of creating knowledge with scrum teams include team structures, where teams are build up of many specialized skills thus creating silo success criteria and outcomes. Additionally, scrum teams can also been seen doing “foundational” work with an excuse to build a sense of predictability. This is precisely why agile relates the term “evolving” to all dynamic aspects of software development including requirements, architecture, design etc..

Defer Commitment – While scrum revolves around the idea of short feedback loops, teams are often challenged with timelines or scope or sometimes both for a variety of reasons. This is commonly observed with organizations that limit agility to the teams but still have maybe a PMO that engages in yearly planning activities thus leading to assumed commitments.

Similarly, at the team level, the inability of the team to meet it’s sprint commitment (even though the term “commitment” has been taken out of the scrum guide), can go against the team leading to compromise in other areas, more often quality.

The lean principle of defer commitments does not mean that the teams do not plan or make uninformed decisions. It encourages that decisions be made at the last responsible moment. Last responsible moment can vary from companies to industries to teams but the basic idea revolves around acknowledging and conducting experiments to enable informed decision making.

“In preparing for battles, I have always found that plans are useless, but planning is indispensable” –  Dwight Eisenhower

Deliver Fast – “Ability to deliver fast” is the most common reason why most companies adopt agile methods. Fast can be interpreted differently in different context. One example is Etsy that delivers code into production multiple times each hour. But not all businesses are the same.

The term “fast” was originally intended to enable fast feedback loops to allow teams to inspect and adapt in their pursuit to cause customer delight.

Every team wants to deliver fast and get value in the hands of the customers as quickly as possible, but most scrum teams are unable to do so for a variety of reasons. Some examples:

  • Organizational and team structures leading to increased complexity
  • Lack of supporting practices and tools
  • Big increments; looking too much into the future
  • Lacking urgency to remove impediments
  • Intent of building a perfect solution

Going back to the principles mentioned earlier, deliver fast can be the outcome of eliminating waste, building quality-in and creating knowledge. A focused effort to apply these principles leads to the lagging outcome of faster delivery

One of the concepts you’ll hear referred to a lot in Lean is “concept to cash”. It refers to the lead time from the time the idea was conceived to when the customers start purchasing it, or it can start adding value by saving us costs, reducing costs, etc.. as fast as possible.

Respect People – The 5 values of scrum (commitment, courage, focus, openness and respect) help build trust within the team and the scrum team members are expected to learn and explore these values as they work with the scrum roles, events and artifacts. However, a common observation is about how most important decisions are taken outside the team that have a direct impact on the team. Simply put, decisions are taken away from the where the work happens.

Another challenge for teams is the issue of psychological safety. In the lean world, respect is all about developing and empowering the people and trusting them to do the right thing. Lean talks about this idea of a “Gemba”, which refers to the process of leaders going and observing where then works happens, conducting enquiries and identifying counter measures for problem solving along with the team.

Lean also encourages respect for people by communicating proactively and effectively, encouraging healthy conflict, surfacing any work-related issues as a team, and empowering each other to do their best work.

Optimize the Whole – Sub-optimization is a serious issue in software development. Mary and Tom point to 2 critical reasons behind the sub-optimization. First is where developers release sloppy code for the sake of speed and second is the long cycle time that is created between developers and testers as a result of handoffs.

Leans suggests use of value stream mapping to design, produce, and deliver a product or service to customer. After identifying how value flows through their teams, many organizations decide to organize their software development teams to be complete, multi-disciplined, co-located product teams, which enables them to have everything they need to deliver a request from start to finish, without reference to other teams.

***

Scrum is a framework which means it is an essential supporting structure or the basic structure underlying a system. Teams that are comfortable with scrum and achieve the expected outcomes can apply the mentioned principles are various levels to quickly transform themselves into a high performing team.

Regardless of which framework the team chooses to adopt, it’s important to understand the principles behind the method in order to ensure a sustainable, disciplined practice. If your team is doing Scrum but is not consciously implementing agile and/or lean principles, the outcomes can be slow and the journey long.

 

 

 

 

How Product Managers Influence Organization Culture

Image courtesy Technical.ly
Image courtesy Technical.ly

Among many others, maximizing value and ensuring ROI are primary responsibilities associated with a Product Manager role. These include activities around market research, customer interaction and much more. All Product Management activities are split across 2 broad categories; strategic and tactical. These activities take away the majority of the Product Manager’s time with limited or no time in hand for the team solving the problem.

A Product Manager’s engagement with their stakeholders highlights a very distinct gap. This gap is caused by the approach driven by local optimization where customer’s priority is about market expectation and their need for new features, management which is concerned about timelines and cost and teams that are about stress and impact of changing business landscape. In a nutshell, each interaction deals with local problems without much attention paid to common business goals and objectives and the missing alignment.

When it comes to development teams, the kind of engagement a Product Manager is able to develop impacts how the team performs. Here are some Product Manager attributes that impact team culture:

Shared Product Vision – Developing a good Product Vision can be difficult. A lot of market data and research goes into understanding what you need to build and why. Knowing the vision of the product can greatly impact the behavior of the team. It is imperative that the people involved in building the product buy into it. A lack of it can cause the team member to be demotivated or follow their own goals which make it harder to achieve product success. An inspiring vision that is able to articulate the positive change it will bring can go a long way in how teams think, engage and innovate.

A vision also helps in guiding the decisions of the team. A team member who will be able to challenge a Product Manager on a decision that deviates from the vision is typically a motivated team member.

A Product Manager should bring in the team together every once in a while and have them articulate the product vision to ensure shared understanding.

Product Strategy – The next step is to have a product strategy. A strategy is developed taking into consideration market and customer needs, key product differentiators and focused outcomes. While Product Managers own the strategy, an inclusive approach where the team gets to influence strategic decisions based on their understanding of business and product helps builds a culture of trust.

Focus on the problem – It is commonly said and understood that while Product Managers focus on the “WHAT” and “WHY” of the problem, they should trust the team to come up with the “HOW”. Many Product Managers indulge in influencing decisions about the “HOW” suggesting lack of ability in the team to solve problems.

While organizations invest heavily in hiring people with the right skills and talent, Product Manager trying to force solutions may suggest their lack of faith in team’s ability and skills. Product Managers and other team members must have mutual respect for each others knowledge and contributions to the team. A Product Manager who shares a problem and trusts the team to find a solution build a culture of collective ownership.

Acknowledge unknowns and need for experimentation – Just like all business solutions may not be successful, technical solutions can fail too. Expecting development teams to be first time right can kill the creative capabilities and limit the team from taking risks.

Product Managers should encourage the team to experiment and take risks towards building next generation solutions while staying aligned with the latest technology and industry trends. Technology teams understand market and business constraints and should be trusted to provide solutions that work around the constraints and provide business value. This will also lead to building a culture of celebrating failure.

Allow technology to drive value – We live in the era of technology innovation where the biggest businesses have been successful by leveraging technology to solve the most common problems. Most successful enterprises are creating a “playground” for exploration to explore new technologies cause disruption.

Driving business value is crucial for Product Managers but the most innovative outcomes are produced by allowing technology to remain on the forefront of problem-solving. This needs to have a mindset and culture of collaborative ideation and problem solving to use to best of both worlds to create competitive advantage and create a culture of innovation.

Wrap Up: The most successful enterprises are using joint business and technology portfolio to innovate and create the most innovative product offering. Product Managers can play a critical role in practicing this at the team level by putting the above-mentioned behaviors in practice.

If you are a Product Manager and you have other ideas that can help transform organization cultures, please leave a comment.