Following up on my recent Quora answer, here is a big list of product management best practices, as well as my personal recommendations:
- Kano model => Delighters, Satisfiers, Basic expectations
- MoSCoW method => Must, Should, Could, Won’t
- The KJ-Technique => Voting and ranking groups around a focus question
- Outcome-Driven Innovation => Uses an “opportunity algorithm” to measure and rank innovation opportunities
Why? It’s quick, simple and answers the core problems most companies are faced with — “What features should I get rid of, what should I do more of, and where should I innovate?”.
- User stories => As a, I want, So that
- Job stories => When, I want to, So I can
- Business Requirements Document (BRD)
- Product Requirements Document (PRD)
Why? Mapping solutions (user stories) to core customer goals (job stories) helps ensure you’re building a product people will actually use. When you realize that any goal has many solutions, you can begin to prioritize your effort to get the 80% value out of the 20% of your effort.
Why? OKRs set high level goals (objectives) and explicit measurable tasks on how to achieve these (key results). At an abstract level, these can tie to your product roadmap. This enables teams to act autonomously, focus on goals and just generally do more by mitigating the common question of “What should I do next?”.
Software delivery methodologies
Why? If you knew what you needed to build and who for, you’d be making millions in a matter of days. Unfortunately, your amazing idea has probably been built by 10 other companies. And, if it hasn’t, you’ll quickly find that your idea will change over the course of its life because of your market, technology and an evolving customer base. In summary, apply lean and ‘agile’ thinking and you’ll be able to iterate on your idea faster, and hit that sweet spot of product/market fit. The methodology doesn’t matter, what matters is that you stay objective. On a side note, I find that time-boxed iterations can incentivize unexpected ‘shortcuts’ to be taken that can do more harm than good (e.g. trying to push work to ‘done’, and introducing technical debt, because ‘done’ is the metric of success). Try to avoid this.
- Priority Buckets => Now, Next, Later
- 7-Part Product Roadmap => First principles, Goals & progress against goals, Recent updates, Themes (near-term), Themes (long-term), Individual projects, Appendices
- Product Strategy Roadmap => High level (strategic) marketing-esque announcements of (future) product improvements
- Categorize, Cluster, Communication => Current Quarter, Next Quarter, Next 12 Months, Future.
- Three Feature Buckets => Customer requests, Metrics movers, Customer delight
Why? A simple Priority Bucket list helps you focus on the ‘now’ and ‘next’. It also allows you to keep the ‘Later’ in mind, but (importantly) out of sight. From there, you can fill up your ‘buckets’ with minimum marketable features. Building features with an MVP mindset ensures you don’t build the wrong things upfront, since it forces you to rely on feedback over making long-term assumptions.
Project Delivery Metrics
- Cycle time => The time you start a task until it’s completed.
- Lead time => The time a task is created until it’s completed.
- Burn-down chart => A visualization of the daily progress of an iteration of work.
Why? Using metrics to predict future development timelines usually breaks down. There are just too many variables to account for. By looking at metrics like cycle time and lead time in retrospective, you can quickly (and visually, if you use a time-in-process chart) find and discuss bottlenecks in your process. Or, you can see what what’s working so you can double down on it.
- Relative estimates => Flexible, determined by factors you define (e.g. complexity, risk, repetition). Examples include story points & t-shirt sizing.
- Absolute estimates => Pre-determined, with an absolute time (e.g. 1 day).
Why? Absolute estimates crumble at the hands of projects where you’re doing something for the first time. And that seems to be the case for 99% of tasks. Just logically thinking about it, the likelihood of your upfront ‘guess’ being correct is pretty low at best. On the other hand, relative estimates scale based on a range of proxies you determine (e.g. this is usually risk, repetition, complexity, etc.). If an initially ‘small’ problem becomes really big, you can know that a ‘large’ problem of equal complexity should be really big relative to its first estimated size. While relative estimates aren’t a silver bullet, they’re our best bet at estimating effort for now.
- Quora answers => For example, product x vs. y posts, feature requests, praise or complaints.
- Competitor’s feedback forums, testimonials and complains => Find what’s already working and features customers are already requesting.
- Customer interviews, surveys and calls => Ask customers what’s working and what they want to achieve.
- Support tickets => Find what customers are already having issues with.
- Internal team => Other teams in your company interact with your customers and can simply bring new perspectives to the table.
Why? Your intuition will break down at some point. Even then, you should never use it alone in the first place. Bring in as many data sources as possible and make the best product decisions based off that. Whether you succeed or fail, you’ll learn and, over time, make better decisions.
- Retrospective => Collect data, look for patterns, determine actions
- Post-Implementation Review => Review of the project after it’s done
- Stand-up meeting => Short, daily checkup of how the team is progressing
Why? You should be frequently trying to improve your teams by retrospectively looking at task and team performance. It’ll help you fix bottlenecks faster. In parallel, you can “run the board” to find and fix current blockers on your Kanban board ASAP.
Why? Personal preference. Plus, Slack slickly integrates with a bunch of other tools. And, calls to the USA are free with Google Hangouts (for now).