When diving into the Product Management world, some questions seem to come up the most often. We had a couple of our instructors answer some of the most frequent questions that we receive here at Product Gym.
- Strategic initiative to work cross functionally
- Most important business metric
- Prioritizing features in new products
- Interviewing customers
- Wireframing for prototypes
- PRD (Product Requirements Document)
What was your last experience leading a strategic initiative where you had to work cross functionally? How did you know if the project was successful?
Adding a search-based navigation system to an analytics dashboard was a pretty wide-ranging effort. The concept originally surfaced from the Sales team, looking to remove friction from the onsite demos. Because this feature aimed to offer an exceptionally faster path to all the views in the application, I worked with Product Design to interview our power users, and investigate their instincts for how to search for views by typing. We took the resultant data to shape the input patterns, Engineering had a lot to offer in terms of the tech to handle the user input quickly and power the UI to guide them to what they need. I then worked closely with Product Marketing to make the user guidance documentation as simple as possible.
In the end it was a huge success, because we had reduced the number of steps to get to a given from (in some cases) 5 clicks down to one navigation action, driving lifts in active usage and NPS. By maintaining a strong integration of stakeholder feedback, I was able to manage expectations tightly and ensure satisfaction across the business as well as with users.
What is the most important business metric you currently own? What is a project that moved that metric?
I like to measure customer success in terms of Net Promoter Score, the addition of the user-focused search navigation feature addressed the biggest user pain points around navigation, and had a direct correlation on lifting the NPS.
How do you prioritize features in a new product or a release of an existing product?
On the B2B sales cycle, we work to evaluate 3 revenue categories: new business, retention and upsell. By cataloging the sources of request for features, we can attach potential revenue to the features (Business Value). Keeping an eye on the percent progress of sales initiatives and churn risk/upsell willingness, we can properly weigh the value of new features against request priority from users (User Value). These two valuation scores are then contrasted with estimated effort and cost to build, and a prioritized list is presented to key stakeholders for context. Finally I make decisions about which priorities to address in what order, and get final stakeholder sign-off. We repeat the process on a quarterly basis, with monthly check-ins for reprioritization.
How do you interview your customers. What are the common questions? What is the process?
Generally, I like to make a social call and ask open-ended questions around activity surrounding product or feature usage. I look for:
- Context – “what are you usually doing when you decide to do X?”
- Emotion – “how does this particular problem affect your mood or ability to get your work done?”
- Ingenuity – “how do you usually solve this problem with the tools you have?”
Question commonality tends to be more categorical—there are a set of assumptions that need to be validated based on whether you are looking to enter a new market, create a new product, or improve existing features.
How do you do wireframing for your prototypes? What experience do you have?
I like paper prototyping and Balsamiq for speed of execution. I have worked on both product and UX teams as designer at many levels, but ideally, I like to empower the product designers I work with to own the execution of prototypes, and look for ways to enable an organic prototyping discipline utilizing a fork of the official design system when adding features to production software.
What is your day like? How do you communicate with designers and engineers?
I tend to spend my days split between meetings, analysis, and execution, but each day tends to have its own theme based on its position in the week. Early in the week I’m focused on gathering information and updating weekly task plans / confirming meetings. Midweek, I’m meeting with customers, writing product definition and planning for upcoming initiatives. Later in the week, I’m more focused on documentation and team building. I like to have cadence meetings with leaders on the design and engineering teams, but will often pair with engineers and designers to work through specific problems at their desk or on a whiteboard intra-sprint.
How do you come up with PRD (Product Requirements Document)?
I like to follow an iterative 5 stage research and definition process with PRD in the middle.
- Initially, I meet with business stakeholders to identify the problem they’re seeking to solve. We’ll then detail the data driving us to believe that there is a market for the solution. We’ll then take validated ideas to stakeholders across the business to assess the strategic and revenue value of the solution, and capture any hard requirements the solution must meet.
- Next, if the solution will require users to interact with software, I initiate user interviews in order to identify the user personas involved, and develop navigation and other interface requirements that go immediately into design execution.
- With the business and UX constraints established, we document the Product requirements: I write out an overview of the solution, followed by a detailed list of Job Stories that are then translated directly to JIRA tickets with Interface mockups and prototypes as needed. A strategy for measuring usage, and key performance metrics are defined at this point and ticketed out as well.
- With the Product requirements fleshed out and the validated solution being designed, JIRA tickets are reviewed by the Engineering team for technical details such as data models and architectural constraints and documented along with any Testing requirements from the QA team.
- Finally, we develop Go-to-Market requirements that make sure the solution is offered to the correct user personas with the right amount of educational material to drive adoption and gather feedback.
What does agile mean to you and how do you deal with the process ?
Agile at its heart is the spirit of making small calculated moves while keeping an eye on the success of each effort, as well as changes in the market landscape, all feeding into the next small calculated move. I prefer to operate a number of cadences in order to remain flexible while keeping the drum beating to an overall vision for where the product is headed. When it comes to development, I’ve had the best experience with 2-week sprints, but I like to invite the engineers to dictate the cycle pace they prefer. At the top of each sprint, we discuss the goals for development and ratify any concerns in terms of dependencies and blockages, daily or alternating-day statuses via standup or slack, and a team retrospective and planning process. This dev cycle fits well into a quarterly roadmap update cycle with monthly adjustments – I prefer to have a full year themed while clarifying the coming quarter, so adjustments to the overall direction can be made and communicated.