The Essential Product Development Toolkit for Internal Product Managers
Effectively drive internal product development with the aid of high quality product artifacts
In my previous article, I talked about the importance of internal products as the backbone of enterprise efficiency.
Although there is general consensus on the value proposition of well-built internal products, in reality companies rarely invest the same amount of resources and professionalism in the development of in-house tools as compared to external customer-facing products.
Internal products, after all, are generally perceived as cost centers rather than profit generators. It is therefore natural for companies to try and minimize this cost and settle for ‘good enough’.
Whilst it’s good practice to show a lot of love to your internal tools, one response to the call to love your internal products as much as your external products might be… ‘To create internal facing products using the same high standards as external products isn’t just unrealistic, it’s a waste of our time.’ — How to Build Better Internal Tools
Rigorous product development depends on actionable product artifacts
Resource scarcity and skepticism over product value are not challenges that are unique to internal product managers. However, I believe that these constraints and the general lower standards expected of internal products should not compromise the rigour of the internal product development process. In fact, it is precisely under these limitations that innovation, resourcefulness and strong execution abilities are required of the product manager.
So how can an internal PM uphold a level of professional excellence in product delivery that is on par with external products?
One practical way is to create and maintain a strong set of product artifacts. These are the collection of ideas, blueprints and frameworks that internal PMs can rely on to drive product development and to serve as the canvas for stakeholder communication. In the context of an agile development team, product artifacts are ‘living documentations’ that continue to evolve and expand through the product development cycle.
Addressing Key Product Development Questions
Of course, there are a multitude of product artifacts that can serve as useful tools for product development.
In this post, I will focus on three essential product artifacts that are highly actionable and serve as beacons in addressing fundamental product development questions.
- What should I be building? — Create user research documentations to compile user feedback and zoom in on the highest value problems to solve.
- How to prioritise what to build? — Develop a feature prioritization framework to systematically score and determine the relative priorities of features in the backlog.
- How to ensure it’s built right? — Compose detailed user acceptance criteria to facilitate testing and to ensure that your product would function as intended.
What should I be building? — User Research Documentations
As an internal PM, you may not enjoy the luxury of having dedicated UX experts on your team to provide professional user research support. In this case, the PM would usually need to take up the mantle of conducting user research.
While internal users are easily accessible, this can be both an advantage and distraction.
In the short term, the regular chatter of user complaints and frequent requests coming from various teams may drive the PM to gravitate towards ‘feature factory’ mode in order to meet urgent user needs.
However over the longer term horizon, PMs should leverage the user proximity to regularly engage with users and stakeholders as part of the product planning and design process. In particular, internal user research can provide insights on:
- Micro issues — User problems and pain points at the individual level.
- Macro issues — Inefficient processes and workflows at the corporate level.
- Design thinking — Facilitating a user-centric approach to product design.
- Utility — Understanding from a user’s perspective how features are valued and utilized.
Collecting user research data through user interviews
There are many ways to collect user research data including user surveys, competitive audits or product metric analysis. My preferred approach is to obtain direct qualitative inputs from users through user interviews.
Despite being qualitative and open-ended, user interviews can be standardized through structured feedback collection and following the methodical steps outlined below. You can even create master templates that can be quickly customized and adapted across different user groups.
1. Pre-interview
Prepare a user research plan
In the pre-interview stage, it is good practice to prepare a user research plan. This process ensures that your research purpose and focus areas are clearly documented before embarking on the interview.
The plan should cover the following areas:
- Key objectives. Define clear goals for your user research. For example, your objective may be to validate a new product idea; or it could be getting user inputs on a recently rolled out feature. If possible, include relevant product metrics or KPIs that can be used as success indicators for subsequent feature implementation.
- User research scope. Highlight specific product areas that you’re trying to improve or develop. This would help to keep your interview process tight and focused. The scope definition can be structured based on question themes (eg. usability, efficiency, user goals, pain points) or specific user scenarios (eg. invoice generation, data asset search).
- Baseline observations. Prior to the interview, it is useful to get a baseline understanding of the current performance of your product through dogfooding and analyzing user metrics. Form some hypotheses about what you think you know about the users. This can help you further narrow the interview scope to the most critical areas of interest.
- Interview candidate selection. Select and list down interview participants who can provide useful insights that are aligned with your user research objectives. If your product serves different user groups, consider segmenting your users and interviewing them in separate sessions or focus groups. In this way, you can better organize user feedback to identify trends and disparities among different user types.
- Discussion guide. Create a discussion guide ahead of the interview to keep you focused on your interview objectives and ensure a consistent interview process across interview candidates. The discussion guide should include a list of opening and follow up questions covering the key themes or user scenarios that you have determined in the user research scope.
Note: In order to elicit the most useful and honest feedback from our users, it is important to adopt user interview best practices and present questions in a neutral and open-ended manner to avoid introducing bias in users’ responses.
2. Post-interview
Extract key insights
Making sense of the vast amount of unstructured qualitative user feedback gathered at the end of the interview sessions can be challenging. The objective at this stage is to note down and catalog important themes, trends and patterns.
It is highly recommended to first consolidate all of your notes and raw interview transcripts in a single location for analysis. After organizing your notes, here are some ways you can create artifacts that can help you to extract value from your interview data:
- Group user feedback on post-it notes to identify common user feedback and pain points.
- Create a spreadsheet and summarize key observations from each interview.
- Use a user research analysis tool such as Epiphany to organize your learning points and find insights that can inform your product decisions.
Summary
Internal PMs often receive a constant stream of ad-hoc requirements from internal users which can be chaotic and disorienting. User research helps to manage this cacophony by providing an objective method to capture and organize user feedback to support product planning.
These powerful insights help PMs better understand user problems and reduce uncertainty around user needs. By incorporating user requirements upfront, internal PMs can make better informed, user-driven product decisions and thereby increase overall user satisfaction.
How to prioritize what to build? — Feature Prioritization Framework
Now that you have collected a significant amount of qualitative feedback and feature ideas from user interviews, the next step is to decide how to prioritize which features to start building.
Managing the perennial tension between competing user priorities and limited engineering resources is one of the core skillsets required of a PM. To perform well in this task, you need both a rigorous process as well as a mindset of ruthless prioritization.
Creating a systematic feature value scoring framework is one way to quantify and rank the relative priorities of user requests. This entails coming up with a list of scoring criteria for each value category and assigning weights to them. Using this methodology, the scores of each backlog requirement can then be tallied and ranked to help the PM make prioritization decisions.
I share below a general scoring framework based on two key dimensions — business value and user value.
Your goal with prioritization is to always be doing the work that maximizes customer value created over time. — Ruthless Prioritization
Business value scoring framework
There are a few criteria you can score against to determine the relative business value of a particular user requirement or feature. This would depend on various factors such as the primary purpose of the product you are building and the current business priorities.
For example, if user growth is the company’s strategic priority in the current quarter, then a feature supporting this thrust would garner a higher score compared to another feature with low impact on user growth.
As previously highlighted, internal products may not always drive business results directly. Keeping this in mind, measuring business value for internal products often means estimating the indirect impact or the enablement potential for other business drivers. For instance, to support a new product launch, we may need to build a new data analytics module to analyze sales data and drive marketing efforts, which are critical to business growth.
Some of the areas that I would typically include in the business value scoring matrix include:
- Revenue potential. Is there potential for a particular feature to support revenue generation? This could be either enabling new revenue streams or driving existing revenue growth.
- Cost savings. Can this feature bring about significant cost savings? This could be in terms of manpower costs, recurrent expenditures (eg. software subscriptions) or future investments (eg. buy vs. build costs).
- Risk mitigation. Is the feature necessary to support risk, security or compliance requirements? These features would often be considered top priority due to the significant negative implications involved if not delivered.
User value scoring framework
User value is another key area that can be quantified and ranked in your feature prioritization matrix. For internal products in general, productivity improvement is often the most salient measure of user value. Or as the book Lean Analytics puts it, ‘the One Metric That Matters here is pain’.
So how do we quantify user pain, and by extension the relative weightage we should assign to specific feature values?
Here are some of the potential scoring criteria that you can consider:
- Man-hour savings. Estimated time savings that target user groups can gain with the delivery of the new feature.
- Incidence rate of problems. During user interviews, look out for common pain points that have been repeatedly highlighted by different user groups. Solutions to these problems should receive higher scores in proportion to the scope of its impact.
- Problem solving effort. According to Lean Analytics, a good indication that a particular problem is worth solving is whether users have already been actively trying to solve it themselves. For example, issues for which users have bothered to create workaround solutions using spreadsheets or other manual tools should receive a higher user value score.
Summary
The feature prioritization framework is an actionable tool that helps PMs systematically determine how to allocate limited engineering resources towards developing features that deliver the highest user values.
Although the scoring methodology and weightage can be somewhat arbitrary, it is nonetheless a good starting point to help the product team as a whole evaluate prioritization decisions together. With practice and regular validation with users, it is possible to become more internally consistent in scoring and making tradeoffs.
Tip: Calculate the ROI of each project by estimating the expected user value over the amount of engineering effort it would take. This would give you an even better measure for prioritization that takes into account the value created per unit time of engineering effort required.
How to ensure it’s built right? — User Acceptance Criteria
User acceptance criteria is a product artifact that goes hand in hand with user stories to determine whether a product team has indeed successfully delivered on the promised user requirements.
If user stories represent succinct requirement pitches, then user acceptance criteria spell out the specific nuts and bolts of how product features should function. Good acceptance criteria help to establish product specification benchmarks and ensure that the product is built right.
Why do we need acceptance criteria?
- To define boundaries. Acceptance criteria help development teams define the boundaries of a user story by clearly stating what is included and excluded from the scope of the user story. In other words, acceptance criteria facilitate a common understanding of ‘Definition of Done’.
- To reach consensus. Clear acceptance criteria help to align expectations among the product team, users and key stakeholders. The product team knows exactly what are the performance requirements required, just as the user knows what to expect from the end-product.
- To serve as a basis for testing. Acceptance criteria is used by QA testers as the basis to develop test cases and a comprehensive test plan. Each acceptance criterion should be independently testable and have a clear pass or fail scenario.
- To allow for accurate planning and estimation. Acceptance criteria scenarios allow for the appropriate division of user stories into tasks so that the development effort can be correctly estimated and planned.
Rule-oriented acceptance criteria checklist
Acceptance criteria can be included as part of the Product Requirement Document. These specifications also serve as a useful guide for building wireframes and prototypes to ensure that the UI design meets user requirements.
My preferred approach is to write out acceptance criteria in the format of a checklist. The list should be directly tied to a specific user story, with each checklist item described in clear, concise and simple language.
Take note of the following points when developing the acceptance criteria checklist:
- Convey the intention of the user, not just the mechanical behavior of specific feature elements.
- Be concise but specific. As far as possible, try to cover the important functional states and scenarios that users might encounter such as active or inactive states of certain buttons under different circumstances.
- Include ‘negative criteria’ (how the feature should not behave) and ‘edge cases’ (how to deal with extreme or exceptional scenarios). This level of specification would help to minimize bugs and performance issues when the feature is released.
Summary
Writing user acceptance criteria helps the PM capture product requirements in precise and accurate terms. Acceptance criteria is also an important collaboration tool that syncs up the work of the PM and QA team. With the aid of clear feature element descriptions, QA testers can be much more efficient in developing test cases.
Acceptance criteria, user stories and product mock ups, combine to formulate a complete picture of product specifications. Using this pre-established rubric, the PM can facilitate a common understanding of the ‘Definition of Done’ among different parties and ensure successful delivery of requirements.
Key Takeaways
Product artifacts function not just as information repositories but also as the basis for organizing and directing the work of a product team. As such, the quality and clarity of actionable product artifacts are closely associated with how well the product team can execute towards product delivery. High quality product documentation provides the following benefits:
- Stakeholder communication. Crystallising your ideas in visual form can help to clearly explain feature mechanics, articulate value and align product vision across different stakeholder groups.
- Decision-making. Having structured frameworks is a great way to guide decision-making. This can significantly reduce the time and cognitive load expended on prioritizing product decisions and user requirements.
- Workflow management. Internal PMs often receive direct feature requests from users which can create distractions and increase the risk of scope creep. Good documentation help to structure requirements in a coherent and cohesive manner to help the product team remain focused.
For the internal PM, determining what to build, which features to prioritize and how to build things right are core product management skills that require deliberate practice to become better at.
Creating high quality product artifacts allows you to hone this craft. At the same time, these documents serve as task mapping tools to ensure your plans are not just paper strategies but also action-oriented towards delivering the highest user value under the constraints of time and resources.
If you found this article useful, please recommend or share it. You are also welcome to share any thoughts or comments with me here.
