Context, Purpose, and Anatomy of an Effective Concept Story

One of the most useful artifacts in a design-led innovation and product development process is the concept story. While there are many good formats for this story, I developed my own version about 10 years back and fine tuned it with multiple teams, projects and companies. It worked very well for me and my colleagues who adopted it. It has played an important role in most successful products I designed and delivered in the past decade.

The context where a concept story fits

To understand why and when a concept story makes sense, we can start by looking  at the design-led innovation framework.  The design led innovation or design thinking process always starts with a user and a mystery around the user. 

For example, the business or product leadership team in a brokerage company might wonder why they are not able to attract young people to their investment platform. After some initial interviews they may arrive at the heuristic stage where they conclude that, it may be because young people usually have less money to invest, which is a hurdle for investing in companies they want to invest in. So they may hypothesize that providing the ability to buy fractional shares might attract  young people to their investing platform. The third stage in the framework is the algorithm phase where a detailed way of accomplishing the goal is defined. The fourth stage is where the algorithm or process is turned into software code where it is made reliable and repeatable.  A concept story is very effective in the heuristic stage of the design led innovation process. To explain the stage where the story fits in, please have a look at the diagram and the example scenario below.

Figure 1: A concept story’s place in the design-led innovation framework. 

Purpose of a concept story

A concept story has three main purposes. First, to identify the user and empathize with her. Second, to articulate the value the solution will create for her. Third, to visualize how a use may interact with the software and other supporting personas.

The result of a concept story creation process is clarity of thought in the mind of the product manager, the designer, the engineering architect and a common understanding of the mental model among all team members.

Most of the value of a concept story will be achieved, even if the product managers and designer do not show the concept story to anyone else. Another advantage of a concept story is to serve as a communication artifact, particularly when a product manager is working across countries, time zones, cultures and organizations. Since pictures and storytelling were invented long before language was invented, they are several times more effective in communicating an idea compared to words. Even if a product manager is confident about her command over the written word, the recipients of the written word may not have the skill to understand the written word, particularly if they are from another country, culture or region. I have noticed that a good concept story takes about 3 hours to put together but eliminates up to 20 person hours in work sessions. 

The Anatomy of an effective concept story

There are five  main attributes in an effective concept story.  

• First, the concept story should have a name that mentions the user and what she accomplishes using the product or feature. 
• Second, the concept story should describe the user persona, her pain points, and the supporting personas.
• Third, the concept story should mention a trigger for the user journey.
• Fourth, the concept story should show how a user interacts with the software or other personas to accomplish her task. This usually is accompanied by hand drawn low fidelity mockups.
• Finally, the concept story should state what the user accomplished.

Things to avoid while writing a concept story

• A concept story should follow a single journey. The story should not contain multiple branches.

Figure: The Anatomy of an effective concept story

Writing a concept story is like cooking a dish. The best way to master the craft of a concept story is to build one and use it as an artifact to refine your thinking and to share your thoughts. Although, having appropriate illustrations and a good layout will significantly enhance the thinking and discussions, getting the attributes right is far more important than getting the illustrations or the layout right. 

What is the level of detail we should go to in a concept story?

If you are familiar with Robinhood, the brokerage company, you will realize that the concept story above describes their entire business. The story deliberately leaves out many details, without losing the essence of their business model. Once the main story is agreed upon, you can create more stories for other main use cases. For use cases where the concept is already well understood, you could skip the story and go to the medium fidelity prototype directly.

Is a concept story always required?

To answer this question, it is best to look at the design-led innovation framework and check the stage in which you are at for a particular product or a feature. For example, if based on conversations with existing customers, a new feature is very well understood and can be articulated in the form of a prototype without further internal discussion, then you can skip the concept story and go straight to a medium fidelity prototype. In my experience 95% of product managers do not write a concept story and start with other artifacts and stumble through the process through elaborate in-person work sessions and conversations. Many of them succeed in building the feature. But they are less effective, and less successful compared to those who choose to create a concept story.

Who should create the concept story?

The mental model of the concept story is clearly the responsibility of the product manager. However, all ideas may not always come from the product manager. A senior designer with domain knowledge will have a lot to contribute. An engineering architect may have clear ideas as well. The responsibility of creating a concept story is the job of the product manager. In my experience, I have seen product managers creating the artifact without hands on help from a designer. I have also seen product managers working with a designer to create the low fidelity mockups.  I have seen scenarios where the product manager created the first draft of the concept story and the designers with more formal visual design education and skill, refining the content without altering the product manager’s mental model.

What happens to those who do not write a concept story or follow design led-innovation?

Majority of product teams do not follow design-led innovation. Many of them do succeed in building useful products for their users. However, in such organizations the role of a product manager is that of a business analyst who listens to an existing process or a proposed process and write down the algorithm, in the form of a user story, so that engineers can code it. Such projects may or may not succeed. The solutions will most certainly be inferior to a solution created by a team that follows the design led innovation process. If you want to be an effective product manager, you will be much better off working for an organization that believes in and invests in design-led innovation. Many companies do. Seek them out. Stay away from those who do not invest in this. Because they are less likely to succeed.

Infusing Systematic Innovation Into Product Design and Development

When I build new products from concept to launch, I ask my teams to adopt the design thinking process. For example, when I built a product called Castlight Action, the first several weeks of the project was devoted to listening to benefits leaders from companies such as Walmart, and Mondelez to understand their pain points around health benefits administration and communication. The next several weeks were devoted to coming up with a hypothesis, concept story creation, rapid prototyping, concept validation with targeted users followed by detailed definition, design and development. The product was a commercial success when we launched. Hundreds of customers adopted it and it made millions in revenue every year for Castlight Health. In this project, there was a dedicated team of 70 people with a very clear goal of creating a commercially successful product. 

However, when there is no major program with an ambitious goal, applying the design thinking process became sporadic and inconsistent. Thanks to the efforts of Vince Loomba, head of product operations, Castlight Health had a very robust quarterly planning process for development projects. However, systematic innovation that is sustainable, became particularly hard. Innovation did happen during quarterly execution. But it happened in a hidden factory, led by individual initiative, where progress was hard to track and success hard to measure. Product managers were more focused on getting executives and engineering to invest in their ideas rather than identifying products and features that bring value for customers and become a commercial success. When specific functionality was approved for investment in a quarter, designers and user researchers were given limited time and shorter notices to test the concept and do detailed design. Ruta Raju, Castlight’s head of design at that time pointed out to me that innovation and design projects should be treated as separate projects with specific deliverables rather than hurried predecessors of development projects. I agreed with his observation and promised to work on it. 

I also noticed that in some companies I knew, the executive team and product managers decided to build and release major functionality to customers with little or no customer co-innovation session or concept testing with targeted real users. Such products were not used by customers and months of investment was wasted.

When I had an opportunity to rethink the product management process at Jemstep, I requested my colleague Jason Kim, Director of product operations to separate innovation assignments from development assignments. I suggested that, apart from the regular development assignments for a quarter, we have a set of  innovation assignments with specific deliverables that will become candidates for development assignments in the subsequent quarter. I also requested product managers and designers to plan their time commitments for such assignments every quarter. Jason then created detailed and separate project plans for development assignments and innovation assignments. I identified the skills needed and the tools we need to invest in to support this process. Product managers were trained on specific skills and supported when necessary.

A. Quarterly Innovation Assignments

For innovation assignments, product managers and designers worked together to do the following.

1. Create concept stories with low fidelity mockups.

2. Conduct customer co-innovation sessions to validate hypothesis.

3. Create Medium fidelity prototypes of proposed functionality

4. Conduct concept testing with real users 

5. Calculate the  return on investment for large innovation objectives.

6. Review the solution with internal teams including executive sponsors

For example, when we chose to invest in Individual Retirement Accounts for our robo advice product at Jemstep, Laura Lewison, the lead product manager responsible, did a return on investment analysis for the functionality and had the numbers ready for executive review of quarterly investment. She had co-innovation sessions with our customers to validate the need. She also created medium fidelity prototypes that simulated the functionality completed and tested the concept with real users.

Such innovation projects were given a full calendar quarter. They were treated like any other quarterly objective. The key difference was that the deliverables were user-validated concepts with fully developed medium fidelity prototypes. These deliverables and insights were then used to determine if and when we should invest in developing such functionality.

Every functionality we developed was put through a concept validation test with carefully chosen end users. For example, we could choose users in their forties, living in Texas, who have an individual retirement account, and a bank account to validate a concept. All this can be done in a matter of minutes and insights can be derived in a matter of hours. We used UserTesting.com to recruit users and conduct such validation. When possible, product managers met customers and validated the concepts as well.

B. Quarterly Development Assignments.

For Development projects product managers created product definition documents, epics, user stories, acceptance criteria, and test cases. Designers created high fidelity mockups. Engineers programmed the functionality and demoed their progress every week.

Skills required for such an approach

Because every product and capability was required to go through this framework, product managers and designers will have to learn specific skills. The skills required to perform these tasks are customer co-innovation skills, ability to create a concept story with low fidelity mockups, ability to create a medium fidelity prototype that explains the user journey, ability to conduct moderated and unmoderated concept validations using a service such as UserTesting.com, and the ability to write a product definition document.

Challenges a product leader will face

A product leader taking this approach will face the following challenges. 

First, you may not get executive support for such investment. To get such support, convey that such an approach leads to the development of high quality products in a sustainable manner, while significantly increasing the chances of success. Unfortunately, not every senior executive understands the importance of design thinking and innovation. There may be good business reasons for that belief. My recommendation is to adapt the process to suit the company or find another company to work for. In today's hyper competitive world, companies that take this approach will most likely beat companies that do not take this approach.

Second, a product leader may face resistance from product managers who may not see some of these tasks as their responsibilities. Product designers may see this as product managers encroaching upon their area of expertise. These are genuine concerns and challenges that will have to be addressed. In my experience, particularly at Jemstep, my colleagues found a way to make this happen. There may be exceptions, which the product leader will have to manage.

Why was this not done before?

The above framework sounds logical and simple enough. So, why is this not implemented more broadly in more companies? I believe that design thinking, concept story creation and user validation functions were considered very specialized and expensive activities. In SAP for example such research was conducted in separate buildings where users were recruited and paid to participate in person. Testing one feature used to cost tens of thousands of dollars. That has changed significantly with the advent of online services such as UserTesting.com. Prototyping tools have evolved significantly in the past few years. Today, it is possible for a skilled product manager and designer to simulate a final product pretty quickly. Product managers and the design team at Jemstep led by David Ma built medium fidelity prototypes for every feature and validated most features with real users before the feature was presented as candidates for development. I know from experience that this is possible and doable.

Taking this approach requires hard work, skill and commitment. However, this is a foolproof way to build commercially successful products that customers value.  If there is enough interest, I may expand on this topic a bit more in the future.

Designing the machine that makes the machine

In the past decade, I was hired as a product leader to execute multiple assignments in the human capital management, health benefits and financial services industries. Over the years I learned that when an organization hired me as a product leader they not only hired me to design the machine (the product) but also to design the machine that makes the machine. 

Elon Musk famously pointed out that “The machine that makes the machine is vastly harder than the machine itself”. He added "The extreme difficulty of scaling production of a new technology is not well understood. It is 1000% to 10,000% harder than making a few prototypes."

A product leader is hired to design the machine that makes the machine

Based on my conversations with a few CEOs and business leaders who hired me or wanted to hire me, I determined that the most important value a product leader is expected to bring to the table is the ability to define what the machine that makes the machine is, build it and run it. Very few job descriptions for a product leader (Director, Vice President or Chief Product Officer) call this out clearly, let alone define what that is. Even the hiring managers, who were CEOs of small companies or business leaders in a big company, were not able to articulate this very clearly to me. Instead they said one of the following things. These are real scenarios and quotes from CEOs of companies that hired me or wanted to hire me.

1. Scenario 1: We believe we have a good idea to solve a customer need and have smart engineers who have some solutions. We need a leader to architect the product to ensure that it brings value for customers, validate it with customers and then rapidly scale it for hundreds of customers.

2. Scenario 2: We have identified a major opportunity in our industry. We have smart people who have extensive experience in the industry. We are working with two customers to provide solutions. They are excited about what they see. But every project requires our engineering team and client services team to be involved every day. Our CEO, Client Services and Sales can’t agree on what is priority. We think a product leader can step in and provide a roadmap and deliver high quality products reliably.

3. Scenario 3: We have a product that a few companies bought. We poured smart people and money into it. However we are struggling with delivering the product because there are competing priorities for our customers and we have a hard time delivering anything.
   
   
   Scenarios A, B and C are companies usually at the Series A funding stage if they are private. They may be small divisions within a larger public company. Such divisions resemble a Series A company in terms of purpose, autonomy, responsibility and investment.

4. Scenario 4: We have delivered a very successful product. Millions of users are using it. They love it. We grew rapidly and hired many smart individual contributors who are great at defining and delivering features. However, we need product leaders who make the team work together well to serve customers at a scale we are not used to. The processes, skills, tools, artifacts and frameworks that worked for 1 Million users may not work for the number of users we have now. We need a product leader who can bring experience, hire new talent, mentor them, help them develop professionally, develop new leaders, bring wisdom, and execute with discipline in a regulated industry.  

Let’s now look at how a machine could be designed to meet these needs.

Ray Dalio, the leader of the most successful hedge fund in the world said that the role of a leader is to design a machine that can produce outcomes that meet an organization’s goal. He defined the machine as people and culture. I extended that framework a few years back to include what a product leader’s machine for delivering outcomes for a product company might look like. This is based on my experience executing about 4 assignments in the past decade. It has evolved over time.

Figure: The Product Management Machine

This is how a product leader can go about using this framework when starting a new assignment within the company or in a new company. This could be the first 90 day plan for a product leader.

Before accepting the assignment.

1. Determine the maturity level of product management in the organization. Are you the first product leader? Is product management at an experimental stage? Is it valued and respected? The importance of product management for a company may change over time.

2. Understand the mission of the company. For example, the mission could be to ‘democratize financial advice’, or ‘simplify navigating the healthcare system’. Ensure that you believe in that mission and its impact on society.

3. If you are not familiar with the industry or subdomain, learn and get certified in the specific subdomain. For example, a year before I joined Castlight Health, I got certified in data science and machine learning from Johns Hopkins. When I joined the financial services industry, I called a few of my expert friends and learned the domain through a few work sessions. Recently I added some certifications on Financial Technology from Wharton University. Certifications and learning by conversations are effective ways to understand the domain. Now-a-days, you can learn almost any topic from top universities in a matter of weeks. One of the main skills a product leader needs to have is to know how to learn ten times faster than normal. I highly recommend this course that teaches you how to learn.

After accepting the assignment but before starting it.

1. Listen  to engineering leaders to build credibility. Meet them for coffee or over the phone to understand their point of view and challenges. Convey that you are there to serve them well and you value engineering.

2. Listen to client services leaders or user growth leaders and the support team leader to understand their challenges. Since they are responsible for retaining customers, they can give you raw insights into what is happening on the ground.

Month ONE

1. Understand the top three priorities for the year from the CEO or the business leader responsible. For example, when I joined Jemstep, my manager and Jemstep CEO, Simon Roy made it clear to me that delivering the product to the first major bank customer was the top priority. At Castlight Health, my manager and current CEO Maeve O’Meara made it clear to me that delivering the predictive analytics and programmatic marketing product to Walmart and Mondelez was the top priority for the first year.
   
   

2. People: It is important to understand people, their motivations and their character as quickly as you can.  Once you get the right people in the bus, the bus can be taken to the right destination even if it went in the wrong direction for a few days or weeks. But the wrong people in the bus will ensure that you fail. 
   
   

1. Focus on people. Understand their current assignments and individual feature roadmaps. Recognize overlaps on assignments or features without a clear custodian.

2. Understand their aspirations and mental models.

3. Learn about their prior experience and place them in the pragmatic product management framework. For example, some may be closer to customers and not very close to engineering. Some may have deep experience in analytical thinking but not much experience in day to day execution. Some may be good at design thinking.

4. Look at the artifacts they produce.

5. Assess their mastery of the craft of product management.

6. Design a learning map for everyone based on skill levels and gaps.

7. Do not make any changes to people or organizations at this time.

Unfortunately there is no college degree for product management. It is likely that you will have a team or hire a team of people with varied backgrounds. All product managers irrespective of their responsibilities need to have a basic set of skills. For example, they needed to know how to write a user story. Verify the artifacts of even the most experienced product managers. You would be surprised by the lack of current skills. I normally put everyone through Pragmatic Product Management and key product managers through IDEO’s Design Thinking training programs.

3. Process: The purpose here is to understand if there is a commonly understood way of doing things to collaborate with customers or users, define features, design them, define them for engineering and deliver them.
   
   

1. Understand if there is a process for getting things done.

2. See actual artifacts delivered by the product and design teams. A person’s writing pretty accurately reflects their thinking, knowledge, communication skills and attention to detail. Written communication is critical in today’s world of distributed teams.

3. Understand how the product team collaborates with engineering. Impress upon them that they need to partner with engineering and earn their trust to be successful. 

4. Understand the sharing of responsibilities between product managers and designers. 

5. Make  minor process changes if needed. But do not change the process dramatically in the first month.

MONTH  TWO

4. Platform: The product management team and the design team need effective tools to do their work. These tools do not have to be expensive. Many of these tools can be simple document creation tools or spreadsheet based tools. Some will be off the shelf tools. Ensure that everyone uses them and is skilled at using them.

1. Understand tools used for product definition and design

2. Understand the tools used to deploy or implement the product.

3. Understand the underlying technology platform from the engineering leaders.

5. Product Design: You have to be familiar with the product in month 1. However, in month 2 you need to develop a deeper understanding of every persona, every user Journey, and every possible alternative flow. You may have to work with product managers and designers to accomplish this.

1. Review every persona and the job they want the product to do.

2. Review every user journey in the product. Ask the team for the user flow diagrams. Ask them to create it if needed.

3. Review an entity relationships diagram if available with engineering. If not ask senior product managers to create an entities and logical relationships diagram. Train them to create one if required.

4. Visit three top customers or prospects and conduct co-innovation workshops . If possible, spend a day at your customer support team’s offices and listen to 50 calls. I have not done this in my previous jobs. Instead I listened to recordings of calls that my colleagues made at Castlight. However, colleagues who did this in-person told me that it is very valuable. I plan to do this for future assignments.

MONTH THREE

6. Product Strategy: By month three it will be clear if the team is executing towards the company’s goals. However month 3 is the time to take a deep look at data to verify if the current and planned roadmaps bring value to customers. It is also time to verify if the company is getting back some of the value or will get back some of the value in the future.

1. This is the time to ask senior product managers to perform ROI analysis on major functionality if they have not already done so. 

2. This is also a good time to have a workshop with the senior product managers to review if the features under development align with the goals of the company. Shreyas Doshi of Stripe has done a very good job of defining good and bad product strategy. It is worth a read to understand what needs to be done.

Communicating your work to the organization.

It is important to communicate what you are doing as a product leader to those who do the work following your directions and senior leaders who expect you to produce the desired outcomes. I normally send a weekly work plan email to critical leaders and colleagues outlining the main priorities of the week and what I plan to do and who I plan to work with. It serves many purposes. It helps the product leader earn credibility with product, engineering and key business leaders. It keeps the CEO and senior leaders informed about the areas of focus for the week. More importantly it also points out what the product leader is not planning to do. It gives others an opportunity to point out important tasks if they don’t see it. This is hard to do. But very valuable.

Applying this framework

This framework is based on my experience. It may not apply to every scenario. I am certain it won’t apply to any scenario and organization without some modification. I also want to point out that this is a machine that requires continuous monitoring and nurturing. It is not a self-driving car. It needs a driver, the product leader.

Product leaders could use this framework as a starting point when they start an assignment or a new job. Product managers who aspire to become product leaders could use this framework to understand how their product leaders might be approaching their work. CEOs and business leaders considering hiring product leaders (Directors, Vice Presidents, Chief Product Officers) can use this framework to understand what a product leader can and should bring to their organization. If you use it, let me know. I look forward to learning from all of you.