The Anatomy of An Effective Jobs Definition Document

The Role of a Jobs Definition Document in Customer Management

In enterprise software companies, challenges often arise that test the strength of customer relationships. These challenges may stem from dissatisfaction with a product or service, requiring more than just routine customer service solutions. Such urgent issues often escalate to the sales or executive teams, as they directly impact customer satisfaction, expansions, renewals, and revenue.
Enter the Jobs Definition Document (JDD). This tool empowers product managers to address these high-stakes situations effectively. It serves as a roadmap for action, facilitating two key outcomes:

• Internal Alignment: The JDD helps bring a shared understanding of the customer's problems across all internal departments.
  
• Customer Communication: The JDD enables the product leader to clearly communicate the current capabilities to solve the customer's problems and outline a mutually beneficial action plan.

By providing a structured approach to crisis management, the JDD is invaluable in averting financial repercussions like revenue loss or delays.

Purpose of the Jobs Definition Document

A Jobs Definition Document (JDD) is a crucial discussion artifact between stakeholders within the vendor organization and the customer organization. It aims to:

• Identify all the critical jobs that a customer wants to accomplish.

• Describe the current capabilities that help the customer perform these jobs.

• Clarify the status and scope of these capabilities.

Key Sections of a JDD

A comprehensive JDD is composed of the following main sections. Each bullet point can be a slide.

• Business Scenario Description: A brief context to understand the environment in which the customer operates.

• List of Customers' Jobs-to-be-Done: Enumerate the various tasks or objectives the customer aims to achieve.

• Status of Capabilities: Describe the maturity or availability of capabilities that will assist the customer.

• Job Overviews: A succinct explanation of each job in one slide.

• Name of the Job To Be Done

• Job Description

• Diagram: A visual representation of each job-to-be-done.

• Assumptions, Risks, and Limitations: Qualifications that may affect the capabilities or jobs.

• Next Steps: Action items for moving forward.

Format of a JDD

Since the discussion artifact may have to be presented to an internal and external audience in a short session, a slide presentation format is good. 

Trigger for Creating a JDD

A JDD usually originates when a product leader identifies that a current or potential customer has specific, unmet needs hindering their ability to implement or purchase a solution. The document is usually created when there is an unforeseen problem or escalation because the normal customer support or product research process does not meet the needs of the customer.

Assumptions

• A JDD is not a contract or a Statement of Work (SoW).

• This guide assumes that the readers are familiar with the jobs-to-be-done framework by Prof. Clayton Christensen

• A JDD is not an appropriate artifact to address site reliability or billing issues.

Chief Product Officer Job Description Written by Chat GPT

This week I asked ChatGPT to write a job description for Chief Product Officer. This job description suits any senior product leader responsible for a product area. I did not edit the description. I thought product managers and leaders might find it interesting.

Chief Product Officer Job Description Written by Chat GPT

The Chief Product Officer (CPO) is responsible for overseeing the development and management of a company's products and services. The CPO works closely with the executive team, as well as with design, engineering, and sales teams, to ensure that the company's products meet the needs of its customers and are aligned with the company's overall business strategy.

The CPO is a strategic leader who understands the market and competitors, and can develop and execute a product roadmap that delivers value to customers and differentiates the company from its competitors. The CPO is also responsible for managing the product team, setting goals and priorities, and tracking progress against key performance indicators.

Key responsibilities of the Chief Product Officer include:

• Developing and implementing a product strategy that is aligned with the company's overall business goals and objectives
• 
  
• Leading the product team and providing guidance and direction to ensure that products are delivered on time and within budget
• 
  
• Managing the product development process, including gathering and prioritizing product and customer requirements, defining product vision and roadmaps, and coordinating with cross-functional teams to ensure that products are delivered on time
• 
  
• Tracking and analyzing key performance metrics to identify trends and opportunities, and make data-driven decisions to improve product performance
• 
  
• Collaborating with the sales team to identify new opportunities and support the development of go-to-market strategies
• 
  
• Building and maintaining relationships with key customers, partners, and industry influencers to gather feedback and insights that can inform product development and strategy

Qualifications for the Chief Product Officer role typically include:

• A bachelor's or master's degree in a relevant field, such as business, engineering, or computer science
• 
  
• 10+ years of experience in product management or a related field
• 
  
• Proven track record of success in developing and launching products that meet customer needs and drive business growth
• 
  
• Strong strategic thinking and leadership skills, with the ability to set clear goals and priorities, and motivate and manage a team to achieve them
• 
  
• Excellent communication and interpersonal skills, with the ability to build relationships and collaborate effectively with cross-functional teams and stakeholders at all levels of the organization
• 
  
• Knowledge of market trends, customer needs, and competitive landscape, and the ability to use this information to inform product strategy and development.

Design-led Innovation Can Make a Business Powerful

I believe in design-led innovation for new product development, and enhancing existing products. I have been using the approach of design-led innovation for over a decade in multiple companies to build commercially successful software products. My colleagues and team mates know this. Depending upon their interaction with me, some of them may say that I believe in visiting users, observing them, and listening to their pain points. Some product management colleagues may say that I ask them to tell a story using concept stories. Some may say that I believe in rapid prototyping to understand the user journey. Some may say that, I believe in validating a solution with real users, by walking them through a prototype in person or using tools such as usertesting.com, before engineers start coding the functionality.  My product operations colleagues may say that I ask them to incorporate innovation into quarterly product planning and execution.

However, only a few of my colleagues may realize that this approach is an important business strategy.  In this article, I wanted to share my belief that design-led innovation could be a key business strategy that will lead to inventions that create power.  Such power is necessary for the commercial success of a business. There are several different kinds of business powers. Invention, in my opinion, is the stepping stone to every sustainable business power. The importance of power for a business to be successful is beyond the scope of this article.  A good book on that topic is Seven Powers by Hamilton Helmer. 

To be successful, a business must create something new that produces substantial and sustained economic gain for customers and for themselves. Having access to resources alone may not be enough. Even Qatar, a country that controls 12% of the worlds's natural gas reserves was poor for a long time.  Qatar became wealthy only after investing heavily in inventing the process of liquefaction of natural gas, which made it possible for Qatar to export natural gas to Europe and other parts of Asia. 

Design-led innovation will make practitioners powerful too

I also want to use this article to share my belief that practitioners of design-led innovation, including product managers, designers and executives are more valuable to the industry and hence more powerful themselves. Because they have a framework for creating economic value in a predictable and repeatable manner, they will have better long term personal financial returns as well as job satisfaction. Because the skill of design-led innovation and the resulting invention is hard to be codified and turned into a software algorithm, I believe the skill will always command high compensation.

How is design-led innovation different from other product development approaches?

Most product teams and executives take the approach of analytical thinking or intuitive thinking.

Analytical thinking, where executives and product managers look at market data and determine the potential for a new product or feature, is an essential skill. For example, a product manager for financial advice products may look at a country and determine that there is a market to provide automated advice to people who have about $100,000 invested and are underserved by current financial advisers. They will accurately determine the market size, the potential opportunity and come to a conclusion that if they build a product that serves this market there is money to be made.  They may then proceed to build a product and take it to financial advisors who are their existing customers.  Financial advisors, who are usually compensated based on a percentage of assets under management, may or may not be very interested in the offering because the product essentially replaces them. The product may fail. This is not a hypothetical example. I actually observed this happen. 

Intuitive thinkers, who have prior experience in the domain, may rightly conclude that the process of providing financial advice to people with less money to invest is very cumbersome and we need to simplify the same using technology. Usually, intuitive thinkers are domain experts from clients services, product managers or product designers who have built a prior product, or subject matter experts who spent time in the industry and understand the manual processes and problems involved. Their conclusions will be accurate too. They may decide to reduce the burden of financial advisors with algorithm based financial advice to simplify the process so that financial advisors can serve more clients. Rather than observe and learn from users, they may try to automate existing processes, rather than rethink the processes. Rather than focus on the end user, they may focus on financial advisors, and on themselves, the technology providers. Such an approach is not bad. It might even succeed. For example Wealthfront and Personal Capital did automate the financial advice processes and charged a smaller fee compared to what a human advisor charges. They did become substantial businesses. However, they may not have significant barriers to entry.

A product manager who follows design-led innovation might decide to visit a financial advisor for a co-innovation workshop and talk to her about the challenges her clients face. The financial advisor may talk about how their clients want their adult children to be engaged in the wealth management process. This might uncover the fact that there are 70 Million young people in the US who do not invest outside their retirement plans at all, even though they have some money to invest, simply because they are put off by the process to invest, do not trust current institutions, or do not want to pay the fees involved.  Catering to this market usually involves inventing a product that appeals to them delivered via a channel they are comfortable with. The invention could be a new business model, where there is no fee to the consumer for investing, as Robinhood did, or a transparent fixed low monthly fee for the investor like Acorn did. Such new inventions are most likely to stem out of a design-led innovation process, not just from an analytical or intuitive thinking process. The above companies most likely observed their users, and looked beyond product or features requests from current customers and tried to understand the real pain of their end users and invented new products and services, taking advantage of new technology, to solve their problems. 

What is the design-led innovation process?

The design led innovation process starts with observing users, reaching out and listening to a few of them, coming up with a solution, prototyping it quickly and validating the idea with actual users, and iterating the cycle multiple times. A prototype is not necessarily a piece of clickable software. For example, when Joe Gebbia and Bryan Chesky of AirBnB had an idea for a bed and breakfast, they did not start by building a clickable prototype. They actually rented out a mattress in their San Francisco apartment to designers during a conference to see if the idea will work. When Steve Jobs wanted to build Apple retail stores, he built a full scale retail store prototype inside a warehouse to understand how the store might work, before building real stores. Such product leaders most likely did not start with market analysis or inputs from experts. They most likely called a few potential users, created a tangible experience that users can validate and give meaningful feedback on, and repeated the process multiple times before they reached a product ready for pilot. 

The design led innovation approach does not ignore analytical thinking or intuitive thinking. Instead a product manager adopting the approach will take market research and intuitive inputs into consideration, but observe users directly, understand their journey, recognize their pain points, formulate a solution, prototype it, validate it, repeat the process multiple times until the solution created verifiable value, and then turn that solution into a product and into a strategic advantage for the business.

Figure: Design-led innovation can make a business powerful.

The diagram above is adapted and enhanced by Prashanth based on the book 'The Design of Business' by Roger martin.

Applying design-led innovation to ongoing product development

While I pointed out successful new companies, I have learned from my experience that the same approach of observing, listening, inventing, prototyping and validating before building and scaling a product, applies to product teams that keep improving their product. Not every product team is going to create a Robinhood, Acorn, AirBnB, or Apple retail store every year. It is possible to take a design-led innovation approach to ongoing feature development in existing products. My colleagues and I field tested a framework at Jemstep. It worked well. You can read about how to do it here. 

Does everyone embrace the approach?

All of  the senior executives who hired me to build products did so because they knew that the design-led innovation approach that I took led to commercially successful products. Some senior executives did not believe in the approach. It is most likely because their incentives were aligned towards extracting value from an existing business in the short term rather than building sustainable business advantage. When the executives that I worked with took such a short term approach, the business failed and they eventually left.

Most product management colleagues agree that the approach is effective. Some colleagues who are experienced in the domain were impatient with the approach because they believed that they already knew what to build, because they have done it before. It took me a while to convince them that while their knowledge is valuable, it may be a few years old and may require a second look. Once they accompanied me for co-innovation sessions with customers and users, they came around and adopted the design-led innovation process. Some product management colleagues with business management degrees wondered why I asked them to draw and tell stories when they were meant to do more important things such as market analysis. They too became converts once they started meeting customers and users and started getting their feedback. Such colleagues did not become experts in the process overnight. They worked with product designers in the beginning and slowly gained the necessary skills. Some of my user experience design colleagues wondered why I ask product managers to think about user journeys, when designers have formally learned such things in college and are better trained in creating such artifacts. Slowly but steadily, almost all of them embraced the process, and delivered products successfully. 

How can a product manager or product designer use this information?

If you are a product manager or product designer, you can first find out the product innovation approach your company is taking at this time. Are they taking a design-led innovation approach or are they building products without listening to potential users first. If they are taking the latter approach, they will likely fail sooner or later. Attempt to introduce design-led innovation in your company. If your colleagues do not believe in the approach, keep your skills polished and keep an eye out for other leaders or companies that believe in the approach. If you are considering joining a new company, ask them if they follow a design-led innovation process. Even if they are not, check if they are willing to invest in the process of design-led innovation. If you have the freedom, the money and the authority, implement the design led innovation process in your company. When you hire people, consider people with such skills or experience. The chances of your company’s success and the chances of your personal success will certainly improve if you do so. If your efforts do not bear fruit in one company, do not give up. Remember what Warren Buffet said. “When a management with a reputation for brilliance tackles a business with a reputation for bad economics, it is the reputation of the business that remains intact.” Move on to the next organization with better economics and better leadership and try again. 

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.