Exploring the Power of Solution-Free Zones in Product Discovery

In the fast-paced world of product development, where innovation is the name of the game, it’s easy to get caught up in the rush to find solutions to every problem that arises. With the recent advancements in Artificial Intelligence (AI), not only are companies starting opportunity discussions with AI in mind, they are hiring for talent with AI knowledge irrespective of their problem identification and solving skills. However, there’s immense value in pausing, taking a step back, and exploring the problem space without immediately diving into the realm of solutions. Introducing: Solution-Free Zones.

Solution-free zones are designated spaces or periods within the product discovery process where the focus is solely on understanding and exploring the problem space. These zones provide a safe and structured environment for teams to delve deep into the needs, pain points, and motivations of their users, without the distraction of proposing or discussing specific solutions.

The Problem with Jumping to Solutions

Why is it so important to resist the temptation to jump straight into solution mode? Consider this: When we rush to solutions without fully understanding the problem, we run the risk of solving the wrong problem or implementing solutions that fail to address the underlying needs of our users. This can result in wasted time, resources, and effort, as well as missed opportunities for innovation and growth.

The Benefits of Solution-Free Zones

So, what exactly are the benefits of solution-free zones? Let’s explore a few:

  1. Deep Problem Exploration: By focusing exclusively in the problem space, teams can delve deep into understanding the needs, pain points, and aspirations of their users. This allows for a more nuanced and comprehensive exploration of the problem, uncovering insights that might otherwise be overlooked.
  2. Empathy and Understanding: Solution-free zones foster empathy and understanding by encouraging teams to put themselves in the shoes of their users. This human-centered approach helps teams develop a deeper appreciation for the challenges faced by their users and fuels their motivation to find meaningful solutions.
  3. Creative Problem-Solving: When the pressure to come up with solutions is temporarily lifted, teams are free to explore creative and unconventional approaches to problem-solving. This can lead to breakthrough insights and innovative ideas that might not have surfaced in a solution-focused mindset.
  4. Collaborative Learning: Solution-free zones provide opportunities for cross-functional collaboration and learning. By bringing together individuals from diverse backgrounds and disciplines, teams can leverage their collective expertise to gain new perspectives and insights into the problem space.
  5. Iterative Refinement: Finally, solution-free zones facilitate iterative refinement of problem statements and hypotheses based on ongoing research and feedback. This allows teams to continuously evolve their understanding of the problem space and stay aligned with the evolving needs of their users.

Implementing Solution-Free Zones

So, how can teams implement solution-free zones in their product development process? Here are a few tips:

  • Set Clear Objectives: Clearly define the goals and objectives of the solution-free zone to ensure that everyone is aligned on the purpose and expected outcomes.
  • Use Problem-Focused Tools: Utilize tools such as problem statements, journey maps, empathy maps, and user personas to guide discussions and visualize user needs.
  • Encourage Open-Ended Exploration: Foster an environment where open-ended exploration and curiosity are encouraged, allowing for free-flowing conversations and the exploration of different perspectives.
  • Iterate and Refine: Continuously iterate on problem statements and hypotheses based on ongoing research and feedback, refining your understanding of the problem space over time.

I encourage product leaders to engage in a formal walkthrough of the outcomes and artifacts from the solution-free zones activities before any discussion on solution can take place.

Conclusion

Solution-free zones are a powerful tool for fostering deep understanding, empathy, and innovation in product development. By providing a structured space for teams to explore the problem space without the pressure of proposing solutions, solution-free zones unlock new insights, fuel creativity, and pave the way for more effective and impactful solutions in the long run. So, the next time you find yourself itching to jump straight into solution mode, consider taking a detour through the realm of the problem space—you might just be surprised by what you discover.

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.

Why the idea of a scrum team is so powerful..

1*p7xQMVsJLaXrWqJd9CH_rA

The idea of a team has evolved over the last decade. What started off with a group of people working together to achieve a vague goal under the control of a manager/leader, has in some cases matured where teams are gradually getting more engaged and are aware of the business objectives and are being trusted to get to the finish line.

Screen Shot 2017-08-30 at 6.57.06 PM

The idea of a scrum team presented a new twist to the definition of a team, obviously with its share of discomforts. The thought of a team without a manager, attributes of self organization and self management and emphasis to build trust sounded great but had many heads shaking.

While some organizations have introduced structural changes to embrace 3 scrum roles (Scrum Master, Product Owner, Development team), most organizations are trying to fit the new roles in the context of their current organizational structure or are making a effort to somehow align existing roles to the new ones.

The thought that some existing roles may become redundant can be discomforting and lead to resistance. Some common questions/opinions are highlighted:

  • What about the “other” roles like business analysts, architects, project managers etc..?
  • These people have been with the organization for ever. We can’t let them go.
  • Our product owners are customer facing and have other responsibilities. They cannot be available to the team.
  • A Scrum Master? Who is going to manage the team?
  • Our teams are not mature enough to self organize.

The above questions are clearly indicative of the lack of understanding of the roles and the fact that the organization is focussed on individual roles and not the overarching impact of the roles.

The intent behind the idea of a scrum team was to bring all aspects of product development (business/product, engineering and process) together in order to realize the end goal. While the simplicity of the framework makes it acceptable, the roles continue to operate in isolation and be looked as “speciality driven”. To simplify, Product Managers assume that the responsibility of development team is to implement their ideas only.

As I went around coaching many organizations, I have always made a focussed effort to communicate the attributes of a successful and high performing scrum team, and the attributes that make the idea of a scrum team so powerful. Here are some key attributes that distinguish the great scrum teams from the good ones:

Screen Shot 2017-08-31 at 3.01.06 PMInclusiveness – Scrum teams works best in a inclusive environment. This means that while every individual might have a set of responsibilities that come with his/her role, what creates a big impact is how these roles come together and contribute to the overall success of the product. The idea that only Product Managers are responsible for product strategy, analysis and business decisions and development team implements the decisions made the manager defeats the purpose of a scrum team. In my experience, teams that have been able to achieve the highest level of productivity and created seriously innovative and disruptive products are the ones where these roles collaborate and engage on a day to day basis.

No culture can live if it attempts to be exclusive

Mahatma Gandhi

 For example; the complexity and the time taken to implement a functionality can negate the value of the feature. This information from the development team can impact the priority of the items in the backlog and help the Product Manager make better decisions. So, the idea of a collaborative team that embraces the scrum practices as intended can have a positive impact on the business value produced and accelerate the time take to do so.

For a patient at a hospital going through a surgical procedure involving doctors from a variety of specializations, each doctor constantly provides inputs to others to make sure that every aspect of the patient’s health is known to reduce risks and keep focus on patient’s recovery. Each one is included to achieve the end goal.

Alignment – can go a long way in defining the interest of scrum team members. Often, team members have a very narrow focus on the immediate tasks at hand and lack clarity of the business goals and objectives. Creating alignment is a critical aspect for a scrum team.

Alignment is a practice, not a state.

Unknown

Alignment is critical both at the business and process level and the scrum framework provides practices to help create the alignment through the empirical process control. The scrum team exists so that product, engineering and process can tweak things to stay on course to achieve desired outcome.

Talking about alignment, US and India launched their respective missions to Mars about a year ago. A very big part of the journey to Mars that lasts about a year to complete is to adjust the trajectory of the space vehicle to aligned with the ultimate goal (red planet). This requires various teams handling a multitude of functions to work in complete collaboration and constantly align the vehicle to ensure that the vehicle does not go off course. Any kind of misalignment can have catastrophic results.

Passion  – Alignment creates passion. Once every member of the team is aligned with the end goal of the product with clarity about what defines product success, they contribute in their unique way using their skills to make it big and successful.

Unfortunately, team members work in silos either unaware of the end goal to be achieved or are just not allowed to create impact outside their territory.  There is no focused intent to leverage the team’s creativity, skills or knowledge to drive decisions.

A great leader’s courage to fulfill his vision comes from passion, not position.”

John Maxwell

Time and again companies like Amazon and Google have shared instances where teams were able to come up with innovative solutions just by understanding a problem, doing some experimentation and adapting to feedback and these are the people who feel passionate about what they do. The intent of a scrum team is to create this combined passion for what is expected to be achieved.

Delight – The term delight is often associated with customers but it holds equal importance when it comes to the team we work with. The question one may ask “so how do we delight the team?”. As humans we get a sense of delight from small gestures from people around us. These can include writing a note of gratitude for all they do for the team and the project, engaging in activities to familiarize with the ups and downs of their lives or by just acknowledging what they do as a member of the team.

There is no delight in owning anything unshared

Seneca the younger

When a team comes together to achieve a common purpose and hold each other accountable for the collective success, delight happens. Acts of support, trust, belief, respect, openness result in a overall delightful environment and experience.

Click here to read about an experiment conducted by Thalia Wheatley called impact design to evaluate a delightful experience.

Celebrate – A unique attribute of scrum teams is their ability to celebrate success and failure. The cause of a success or failure is never attributed an individual but the whole team.

“Each day offers a reason to celebrate. Find it and experience true bliss.”

Amy Leigh Mercree

The important aspect of celebration in this case is that the celebration should become part of the team culture. Celebrations should happen frequently, for the whole team and in a way such that it leaves a lasting impact of the team members.

Conclusion: As organizations embrace the scrum team idea, the thought process needs to go beyond the need, skills and title of a role. Instead the focus needs to be towards creating an environment where unique skills are coming together to achieve a common goal in a inclusive environment where there is passion, alignment and celebrations and delight is not just for customer but for every member of the team.