After 10 great years as an instructor with Pragmatic Institute, I left to become an independent consultant. I now assist companies who need help with their product strategy, who need better organizational alignment or generally want to become more market-driven. Over the past year, I have had the privilege to work with several companies, and I now have an even greater appreciation of the challenges that many of you face. Here are a few high-gain activities that can help you be more successful implementing what you learned in a Pragmatic Institute class.
Stop Making Stuff Up
Customers, user observation, surveys, industry analysts, advisory boards, Confluence data, win/loss reports, trade shows—you have many sources of market data that drive your plans. So why does it still feel like you are making most of it up? My observation: Your schedules are overloaded and too many decisions are still being made by those who are not “in” the market.
Look at the calendar of any product team member—every day is usually double and triple booked. Where do you find time to sense the market? Learn to say “no.” Miss some meetings. Don’t clear out your inbox. Focus on the right things. Tools can help: Aha!, ProdPad and ProdPlan are a few. But a tool is not the answer to becoming more market-driven. Without the necessary time in the market, without the time to analyze what the market data tells you, a tool will just document your opinions and ignorance.
If you want credibility with executives and investors, reference a customer and a unique problem that you could solve. The fastest way to prioritize a backlog is to have the hard market evidence that defends your prioritization.
The best way to enjoy this crazy occupation you’ve chosen is to go immerse yourself in the market, not to attend another meeting.
Clarify Product Roles
Why is this still a question today? Pragmatic Institute has taught over 150,000 alumni that the market-driven product professional is:
• The messenger of the market
• The CEO of the product
Simple, straightforward, to the point. But, implementation is not quite as easy. Gnarly questions pop up, like these: Who prioritizes the requirements in the backlog and defects from the support team? Who calls and runs the daily team meetings? Who answers customer questions? Who attends every daily standup meeting? Who reacts to customer issues or product defects? The list can go on and on. It is getting harder for this single role to stay in touch with the market, define a winning strategy and support all of the other departments that are involved with the product.
The introduction of the product owner role is a great improvement over older, waterfall processes, where requirements were often thrown over the wall to development. There was much less interaction between the development and product teams than there is today. But as the needs of your development teams increase, it is imperative that you share the load.
Can a product manager also play the role of product owner in your company? Google it. Many people much smarter than me have stated their views and opinions. There are pros and cons both ways. The key, I’ve found, is in setting the right expectations in the organization, and then determining if you have allocated sufficient resources to meet those expectations. I am not saying that you must have a different person for each role, but leadership needs to be aware of the time demands of trying to do it all, so that the team is not constantly missing everyone’s expectations. Simply put, you must clarify who will act in the following roles:
The voice of the market to the business
Primary outputs: market research, business proposals and plans, competitive strategy, roadmaps, positioning, partnering strategy, goals/epics
The voice of the market to the development team
Primary outputs: user personas, requirements, priorities, market updates and feedback
Streamline Your Product Lifecycle
Startups and mature companies all have some form of product lifecycle (PLC) process. Products get defined, built, delivered, updated, supported and, eventually, are either absorbed by something else or achieve end-of-life status. Companies whose products are delivered in a more continuous delivery method usually have a shorter, more nimble PLC, with fewer steps and documents. Conversely, hardware companies or software companies that release their products less frequently have more of both.
Teams today often regard PLCs as “too waterfall” or “too much process.” It is hard for me to argue with that when I see how many steps and gates have been defined, how many documents are mandated and how many meetings are being held. So why, with agile or scrum, do companies still need a PLC process? So that everyone else can do their jobs! Executives and finance need a PLC to set their budgets and to estimate company revenues, cost and value. Human resources needs a PLC to know what resources are needed and when. Sales needs a PLC so that they can train reps and set quotas for the product. Marketing needs a PLC to update collateral, tools and web content.
Yet many of the PLCs that I see today are outdated and rigid, with too many steps. Audit your PLC. Look for ways to increase both the efficiency and effectiveness. While there is no standard, one-size-fits-all PLC, here are some areas to consider to improve your PLC.
• Standard, lighter-weight strategic roadmaps and business plans earlier in the process that clearly set the business objective and project expectations
• Crisp, short and scheduled updates to leadership from project kickoff through delivery
• Improved market requirements documents (MRDs), or, since most teams are using requirements management tools such as Jira, the complete removal of MRDs
• A release or launch manager role to ensure that as development progresses toward the product release date, others are working back from the date to get all other aspects of the launch completed on time with high quality. We don’t ship if support hasn’t been trained. We don’t ship if user acceptance tests have not been completed. We ship when the product and everyone involved with it are ready.
Document Your Strategy and Business Plans
Too often I’ve heard, “We don’t do business plans anymore” or, “Strategy? I think our executives have one, but I’m not sure what it is.” Alas, teams today are busy building stuff, but often they have little idea if it is the right stuff. Businesses still need a set of prioritized and well-articulated strategic and product objectives that drive corporate investment. Everyone in the organization who has a need to know should have access to them. Here are some things you can do to help.
• First, build a retrospective roadmap to set the context and perspective about how your product has progressed over the past 12 to 18 months. Releases, revenue, clients, headcount, markets, wins, etc.
• Next, build a roadmap that shows your strategy and vision for the future. This should not look like a list of the features that you want to deliver in a given timeframe; rather, it should define the objectives around the markets you plan to capture, the competitors you intend to beat, the users you want to win over and the business expectations/metrics for the product.
• Review and update each product’s business case at least annually. This is not a check-box item, but a thoughtful review of the health of the product and an evaluation of whether you need to make changes in your investment.
• Finally, if your organization is becoming siloed in its plans and metrics, ask the question, “Who owns our cross-product strategy both from the business/marketing and technical perspective?” Also find out whether your PLC includes the necessary checks and balances to ensure that you are leveraging your strengths across all projects, and not creating competing products.
Manage Your Requirements
Are you managing the requirements, or are they managing you? These eight tips will help you take charge.
1. Remember that the customers for your requirements are engineering and development teams. The level of detail and the cadence for which you deliver your requirements will vary a great deal based on their needs. Ask them. Observe how they use the requirements. How can you increase their customer satisfaction?
2. The industry has moved to a more contextual, more user-focused method of writing requirements. The standard best practice is no longer “The product shall …” but “As a < >, I want to < >, so that I < >.” In this transition, make sure that you are writing requirements, not high-level epics or goals. Good requirements provide engineering with enough detail about the problem that they can begin engaging in healthy conversations around designs, estimates and skills.
3. Most products today have both functional and non-functional requirements. Functional requirements are best written as user stories or usage scenarios. Non-functional ones set specific constraints or standards that the product must meet to be marketable (e.g., compliance, performance, platform, security, size, cost). Have the conversation with your team and agree on how to document, prioritize and group your requirements.
4. Product management defines and validates user acceptance. User acceptance tests are not QA, which typically answers questions like: Does it run? Does it operate with the correct inputs and outputs? Does it fail under stress? User acceptance validates that the product solves the market or customer problem as documented in the requirement.
5. User personas give requirements the human context. You should grok the user and communicate those attributes to front-end and back-end developers. Bring in others from the organization that have this insight to help you. User experience (UX) professionals have been trained in this; if you have them, let them define the user personas. And, don’t forget sales engineers, trainers and technical support, who can all provide insight to the different user personas and their problems. Spread the load!
6. Development tasks, system designs and specifications are the domain of the engineering team, not product management. Well-written requirements answer who, why, when/how often and what. They should never answer how.
7. Details in requirements evolve throughout the life of the project. You should provide finer detail and granularity as the team gets closer to doing the development work. Product management needs to keep the requirements pipeline (a.k.a. backlog) primed and filled well ahead of sprints.
8. Define a process for dealing with reactionary customer or organizational demands that can derail the team. It is extremely difficult to define a team’s velocity when they are constantly being redirected to work on the one-offs or the must-fixes that take development time away from the product. Good scrum masters can help here.
Make It Actionable
Pragmatic Institute has outstanding training courses with experienced and talented instructors. They teach many valuable concepts. But, your ultimate success will not be measured by how many courses you’ve attended, but by how you were able to make your company more successful after the training implementing the concepts. These tips can help you do that. What works at one company may not work for yours, and you may just need some outside, objective advice. There are many consultants in the industry to help you with auditing these and many other areas of your product management and PLC processes; get some outside help if you need it. Just make sure it happens.
##Callout##
