My first article in the series talked about establishing Product Vision, Strategy, and Metrics. I gave bonus tips on building Product Vision, Strategy, and Metrics with a detailed example of LinkedIn product Vision strategy. In case you have missed it, give it a read here.
Once your organization has its their Vision, Strategy, and Metrics ready, you must start looking into the granular level of Product Management – Opportunities, Personas, User Journey Mapping, and Roadmap.
Product Opportunity & Discovery – The prioritization of product opportunities is critical, and it is merely a way of creating a hierarchy of the most essential opportunities to determine if solving the specific problem is aligned with the direction of your organization. Personally, I love this is phase because this where product manager can make a huge impact. During this phase there are a lot of assumptions made by the product team. Conducting background research and having a hypothesis driven approach has always worked well for me in the beginning of discovery for any product opportunity. It allows me to have a baseline understanding and frame my discovery in a way where I am maximizing my time. I must validate whether this opportunity is a legitimate problem, how high of priority is it and does it align with our business goals.
Before we can talk about validation it is important that we talk about learning and the speed in which we learn during the discovery phase. Learning velocity is critical to any discovery and that is why I encourage teams to formulate a hypothesis and conduct background research before engaging clients or key business stakeholders. This can save a lot of time when validating the problem and ideating on the solution. Some of the background research I have done in the past is to look at user metrics for existing products and for non-existing products focus on industry and market data then dive into the user journey map. I would even look at what the competitors are doing (a side note: sometimes clients turn to competitors not because they have the right solution but because their product addresses a critical pain point). I wouldn’t spend too much time in this area initially, but having a good understanding helps prior to conversations with clients.
In Product Management, these opportunities are often consolidated in a repository or opportunity backlog, where it is recorded and indexed for future or immediate reference. These opportunities usually come from your client interviews, workshops, innovation labs, consolidated feedback by users, business market opportunities (usually identified internally), or client commitments. If your company is seeking a Digital Transformation path or already started its journey, conduct the same exercise keeping in mind the future state of the technology.
A lot of product managers use Trello or Jira to keep track of their opportunity backlog. Typically, as a rule of thumb I like to stay away from using Jira or ADO to capture ideas on the opportunity level. This creates less noise for the engineering team. I’ll migrate the opportunities to Jira in my product backlog once discovery for that opportunity is complete.
From my experience of dealing with multiple Product teams, conducting Product Discovery is based off identified and prioritized opportunities. I highly recommend “Learn”, “Build”, “Measure” model coined by Eric Reis in his book the Lean Startup.
In short, the premise of this model is to give your Product Team the bandwidth to operate with agility and speed, while continuously looping through the Discovery Process and analyzing the latest Data related to an Opportunity. This will allow teams to work in parallel between discovery and delivery. (Part 3 of this product series will discuss more about the role of product management during the delivery phase).
I have been often asked by the teams about the end goal of identifying opportunities and Product Discovery Phase. The goal for learning about opportunities and more importantly discovery is learning fast and validating. In an agile environment, being able to predict or react to market changes requires product managers to be diligent in their Product Discovery of Opportunities. When evaluating opportunities, it is important to understand who it is impacting, and what is the impact (both from a qualitative and quantitative perspective). In addition, alternatives and competitors must be evaluated to understand the type of solutions or workarounds the user is engaging in.
Involvement in the Discovery Phase
During the discovery phase, often it is assumed that the Product Mangers or Product Owners are the sole responsible individuals of the solution. At Qentelli, we make sure that during discovery a product team identifies and owns the solution collectively. We suggest the same strategy to our client. A member representing product, UX and engineering is highly advised to be part of this process as a team (some teams even involve QA and we absolutely recommend it). The reason for early involvement in the discovery process is to allow for different perspectives and inputs as it relates to user experience, feasibility, and viability.
Client involvement is critical in helping to validate the understanding of the problem and the solution. Once the problem is validated and both parties have a shared understanding and the team have started ideating on a solution, the UX designer can help and assist in designing of mocks and prototypes.
Depending on the engagement, a proof of concept programmatically may be warranted before a full-blown solution is proposed. However, the discovery process should be no different but slightly modified to meet any time restrictions.
Depending on the size of the opportunity the product team may want to release the solution in phases to allow more time for testing. This type of testing and analysis can be performed during a beta phase. This article will not address betas, but it is important to note, most limited releases should be discussed during this phase to seek alignment on the solution. Once discovery is complete the opportunity is then moved from an opportunity backlog to a product backlog. A well-documented product backlog is essential in a product organization to minimize dependencies on individuals that may come and go within a product team.
Moving from Product Opportunities to Personas
Personas – Personas are detailed document of the users who are going to use the product and their characteristics. When evaluating opportunities, there are several questions Product Managers ask, “What is the problem we are trying to solve?” and “Who are we trying to solve for?” The question of who we are trying to solve for is persona related.
Important to note: Although some personas require immediate attention due to usage of the application some companies often forget about the personas that impact the main persona’s role.
Ideal Persona Creation
According to some experts who specialize in marketing and user experience, Persona creation is usually done in a workshop style environment involving members who have an intimate understanding of the user. During your Digital Transformation journey, it is highly recommended to revisit this practice to ensure the most recent version of the personas is evaluated and understood prior to the transformation.
As a product manager, I prefer revisiting Persona’s quarterly or semi-annually. Attitudes, User Behavior, Pain Points and Product Maturity are factors that can change certain attributes for a specific persona. Jeff Patton, said in his book User Story Mapping, “Personas are an example user, customer, or company that uses your product by selecting representative data from your profiles.” Persona profile documentation usually contain pain points, opportunities, personal background, and any additional information that can help in understanding this type of user. Either you can have your marketing team in charge of this process or part of this process. It is highly recommended that product team is involved in either crafting or suggest updates to the personas.
The creation of personas involves a lot of assumptions. Depending on the maturity of the product and organization your assumptions can have a large or small variance. That is why it is important to document conversations you are having with clients to update their behavior or decisions. Sometimes the same persona may have different characteristics depending on the market size of the client's company. For example, an accountant for a small CPA firm may have different duties and responsibilities than for a large enterprise CPA firm like Deloitte or PWC. When job titles are the same but are drastically different amongst organizations, evaluating roles instead of persona may be a better practice. This is true for a lot of SaaS organizations.
To relate with my LinkedIn example, I created two-user personas. In my LinkedIn Example, I evaluated two solutions based on challenges –
- Activating more candidates for job search and
Activating more recruiters for searching candidates I have prepared these two personas for you to relate to the example –
At Qentelli, we work very closely with clients to discover the right opportunities and prioritize them for clients. These discovery and prioritization exercises emphasize how product teams’ work will support overall company vision and goals. We help organizations to plan their goals by month or by quarter to show progress over time towards these goals. The next article in my Product Management series talks about User Journey Mapping and Product Roadmap.