Getting Started: Understanding Customer Needs

This is typically where your journey begins. You might find yourself in a situation where your supervisor or founder instructs you to "build X and launch it next quarter." While this scenario is not indicative of an ideal product development environment, it could be your current reality, and that's perfectly fine. There's usually a genuine customer need underlying this request, and your initial step is to identify who this customer is and what their needs entail.

Identifying Personas

Who are the personas involved? I can almost guarantee your product caters to multiple personas, regardless of what you've been told. Take time to think deeply about each user's context, thought processes, likes, and dislikes. If you haven't created personas before, this is an excellent opportunity to do so—there are many tactical guides available online.

Defining Customer Needs

What problem are you aiming to solve? At this stage, you don't need to draft user stories; instead, explore and document this in a detailed manner.

Current Solutions

How are customers currently addressing this need? You may find a completely unmet need, but it's likely that your customers already have partial solutions. Understanding their current methods will help you identify specific characteristics of potential solutions and highlight quick wins if you release a Minimum Viable Product (MVP) that addresses their most pressing pain points.

Gap Analysis

How significant is this need, and how well is it being addressed currently? This is where you conduct a "Gap Analysis." Don't let the terminology intimidate you; what you're looking for is a matrix that illustrates the importance of a given problem to your user (X-axis) and how effectively their current solution addresses it (Y-axis). You can gather this information through surveys, discussions with your customer advisory board, or insights from your customer success team. Typically, you want to ensure that the problem you identified is both crucial to the customer and inadequately addressed by existing solutions.

Evaluating Business Value

Once you've confirmed a customer's need and established that it presents a high "value to satisfaction" ratio, it's time to assess whether addressing this need is worthwhile for your business. What value will it create, and what are the associated costs? (Marty Cagan discusses this extensively in his book, "Inspired," another excellent read).

An important note before we dive into the questions: there are various types of value beyond just financial gain. As a startup, you may prioritize customer acquisition over profits, so you should focus on how positively your customer acquisition strategy could be affected, rather than simply the monetary potential of the opportunity.

If you're reading this and wondering, "I’m not entirely sure what my business's primary value driver is," I recommend spending some time with your leadership team to clarify this. Understanding this is critical before proceeding, as we will measure our final solution not based on output (Did we release it?), but outcomes (Did it deliver the expected value?).

Exploring Opportunities

What potential does this problem resolution hold for the business? This is straightforward; you will convert this and other factors into measurable metrics in due course. For now, take time to brainstorm all possible positive outcomes that solving this problem could yield. Document them and discuss them with your team to validate your thoughts.

Identifying Risks

This stage can be challenging. No one enjoys beginning an otherwise promising endeavor by contemplating potential pitfalls, but it's essential. Until now, you've identified a legitimate customer need that is more valuable and unmet than others, and you've articulated how it could positively impact your business's KPIs. Keep in mind that more risks will arise as you progress through product development, but it's crucial to document any concerns at this stage.

Consider your user’s journey through your products, features or pages that may get overlooked when this solution is launched, how localization might be impacted, or user personas that won’t benefit from this feature. A quick 30-minute brainstorming session with key stakeholders and your product team can help you identify risks and ensure you're comfortable moving forward.

Oh, and one more thing: you might conclude that, for various reasons, the risks are too substantial to proceed with this solution. This realization can be a positive outcome. The worst scenario is to pursue a solution that ultimately jeopardizes your current product. This is part of the process, and it’s the reason you have multiple issues in your backlog (which could be a topic for another discussion).

The Importance of Saying No

This ability to say "No" to a solution is a crucial skill for product managers. I elaborate on this in the article linked below.

Defining the Solution

Notice the term "Define" in the title; I didn’t say "Design." This distinction is intentional. Before diving into design with your UI/UX team, we must articulate what this solution will encompass, its essence, and what it entails. At this point, think in terms of a Google Doc rather than a Figma file.

However, I want to stress the importance of collaboration at this stage. As a Product Manager, your role is not merely to hand off a list of requirements to a designer and engineer and hope for the best. This topic is too vast to cover comprehensively here, but my primary suggestion is to keep your developers and designers engaged from the outset.

Supporting Data

What data do we have to validate that this is the right solution? Grounding ourselves in data (whether qualitative or quantitative) is generally a good practice, but don't get too hung up on this. It's okay to rely on intuition; your strong product sense is likely a key reason you’re in your current role.

Measurable Goals

What are our measurable goals for this solution, and what metrics will we use to track our progress? Establishing measurable metrics is essential to determine the success of your solution. If you lack data analytics tools (common in early-stage startups), your primary metric could simply be the key business KPI we discussed earlier, such as "Achieve a 15% increase in monthly new user sign-ups." Ideally, you'll be able to create more granular metrics, as "top-level" metrics can be influenced by various factors, complicating your ability to determine whether your solution caused these changes.

Operational Capacity

Can the team manage this solution? This is a vital consideration. Most features are not launched in a vacuum; the solution you release will likely impact other teams within your company. Consider the implications for the Client Success team, who may need to develop new training materials; the Operations team, which will manage distribution; and the sales team, which will need to provide demos. Assess the ripple effects this solution may have on your organization and ensure you can provide support along the way.

Stakeholder Engagement

Who are the stakeholders that need to be involved in this solution? Remember, this is not a digital launch in isolation. You may have business sponsors, key stakeholders from other departments, and other product teams relying on your work. Ensure you account for these individuals (creating a simple RACI diagram can help) and communicate with them effectively.

Communication and Collaboration

Let's keep this simple—just talk about it! Promote it! Encourage team members to challenge it! When coaching new PMs, I often say that one of the most important traits for a PM to possess is collaboration. A significant barrier to a PM's ability to collaborate is ego.

As such, repeat after me: "I am not the smartest member of the team. My colleagues are creative, intelligent individuals with valuable ideas. Engaging with others strengthens my own ideas."

It's crucial to keep your team and stakeholders informed and to invite them into the process. In a future article, I'll discuss how to conduct a Kickoff meeting—a valuable tool for socializing your work. But for now, let's move on to the questions.

Team Awareness

Do my product, design, and engineering teams understand what we aim to build and why? Are other departments aware of how this may impact their work? It’s crucial to communicate this early and often, as your solution does not exist in isolation.

Story Mapping for Clarity

If you've followed my work, you know my affinity for story mapping. It's one of the simplest, most elegant, and effective tools in our craft. If you're unfamiliar with the concept, I have another article detailing story mapping, and Jeff Patton's book, "User Story Mapping," is a must-read for every PM.

The purpose of story mapping at this stage is to identify the user-oriented functionality you will design and release, and to chart how your V1/MVP will evolve into future versions. Step into your users' shoes and envision their interaction with your solution. What steps do they take? What challenges do they face? Next, break this down into iterative releases to determine the simplest viable first release for your feature. We aim to get this solution into users' hands as soon as possible so we can learn and iterate.

Iterative Release Strategy

What is our iterative release strategy? Can we define an MVP that allows us to test the product before its full market launch? The story map will guide you in answering this question!

Design Phase

Now that you have your story map, it's time to begin the design phase. Your designer, responsible for ensuring the solution is usable and understandable, will take the lead. However, this doesn't mean you disengage. I like to be as involved as possible in UX testing, observing "cold users" interact with a prototype and verbalizing their thoughts often reveals new opportunities or issues you and the team hadn't considered.

Prototyping

What is the simplest prototype we can utilize to start testing with users or internal team members? I appreciate wireframes and low-fidelity prototypes for their ability to keep users focused on functionality rather than visual design. Once the solution has a firm definition, ask your designer to create a prototype that accurately illustrates the UX (without focusing on visual/UI design) and arrange some UX research sessions. Be sure to share the prototype internally and set up sessions to gather feedback.

Iterative Changes

What changes do we need to make, and how can we facilitate rapid iteration cycles? The design phase can easily become bogged down if you and your designer allow it. It's essential to move through the Design->Test->Iterate cycle quickly enough to gain confidence in the prototype's functionality, allowing you to proceed to development and collect real feedback from actual users. An old mentor of mine always emphasized that "working software beats a prototype any day," and I wholeheartedly agree.

Development Collaboration

Now that you have a validated story map and a working prototype, it's time to collaborate closely with your developers. Scrutinize the designs and story map to ensure every detail is covered, questions are answered, and error states are analyzed. Involving QA at this stage is also beneficial. Engage engineering before your design team delves too deeply into the details, as they can help validate feasibility and identify potential challenges.

Breaking Down User Stories

How can we translate these user stories into manageable tasks for engineers? This critical step is best done in a collaborative, synchronous environment. Working asynchronously can lead to misunderstandings, resulting in moments of "I thought you meant..."

Acceptance Criteria

What are the acceptance criteria for each story? Your acceptance criteria define what must be true for a story to be considered "Done," along with the standard QA tests and validations needed for production. Crafting excellent acceptance criteria is a skill in itself, and while I wouldn't claim to be an expert, there's plenty of solid, tactical advice available online.

Creating User Stories

Now that you have a comprehensive version of your story map, complete with necessary revisions, it's time to convert this detail into User Stories suitable for tracking in a tool like JIRA. Your Product Owner or Tech Leads will be instrumental in determining how best to break down these stories into manageable tasks that can be completed within a Sprint and demonstrated as functional software.

Sprint Preparation

Are the user stories small enough for the team to start working on? This can be a tricky question, and if you have a PO/Scrum Master, they can offer assistance. A useful trick taught to me by a former Scrum Master is that if there's an "and" in your user story, it likely needs to be divided into multiple stories.

Release Planning

It's critical to establish what "Release" means for this solution. What non-code deployment items need to be addressed to launch this product? Will there be training materials? Updates for the sales team? Marketing or promotional activities? Communication plans? Additionally, consider any data tags needed to capture valuable metrics. Develop a release plan, share it, and revise it based on feedback—this plan will evolve over time, as every company and product has unique requirements for successful launches.

Release Checklist

What is my release checklist? This is the basic form of your release plan. Document all necessary tasks for the solution's launch, including their order and dependencies. For instance, technical considerations might include "we must deploy the mobile feature flag before we can deploy the backend solution," while business considerations might state that "promotional materials need to be printed by DATE to be ready for the launch event." Think holistically about these elements.

Managing Launch Risks

What could cause a delay in the "launch"? Here we revisit the topic of risks, specifically launch risks. Document what could occur if, for example, the printer fails to deliver promotional materials on time—how would you adapt? What would the impact be? While you won't foresee every risk, recording the obvious ones will position you better for challenges ahead.

Marketing Strategies

How and where do we need to promote this solution? Almost always, you must inform customers/users about the new solution they need to engage with. Although this may primarily fall under your marketing team's purview, the Product Manager plays an integral role in this process. In a startup, you might even find yourself wearing the product marketing manager hat! Discuss the marketing plan with your team and identify any dependencies or additional support required for a successful launch.

Internal Communication

What internal communications are necessary before and after the release? Do you want employees to test the product before its general availability? How will you share launch results in an informative and "momentum-building" manner? In larger companies, this could even involve showcasing the project to other teams.

Focus on Outcomes

You're still with me? Great! This is where the real work begins. You get to decide whether you want to be an Output-focused PM or an Outcome-focused PM. As an Output-focused PM, you might have simply sent an email declaring, "Look what we released! Isn't it cool?" and moved on. But you care about Outcomes, right? Instead of merely celebrating the release of the solution, you should prioritize celebrating the outcomes you aimed to achieve and actually accomplished with the launch. This includes sharing any less favorable news, such as not meeting desired outcomes, and looking for ways to refine your approach based on the insights gained.

Sustaining Measurements

It's crucial to share the outcomes regardless of their nature. This fosters accountability within your team and encourages a focus on outcomes. Everyone involved in the product-development-design triad should be accountable for outcomes, even though I argue that the PM bears the most responsibility due to the nature of the role.

Post-Release Evaluation

After some time has passed, has the release met its stated goals? Share these results openly. Have the MTMM (Metric(s) That Matter Most) or core KPIs for our business been positively or negatively affected by this release? Interestingly, the business MTMM may not always align perfectly with "product metrics" (like click-through rates, engagement, conversions, etc.). They typically should correlate, but maintaining both macro-level and micro-level views is essential.

Future Iterations

What will trigger the next iteration release? This is crucial—you're not creating a one-time solution. You're building something designed for longevity, which will undergo continuous improvement to deliver even greater value over time. Consider what factors might indicate it's time to evolve your product.