Becoming Twice as Effective
In May, I presented at P-Camp 2010 Silicon Valley on Lean Product Management. I challenged the audience to consider what would be required to become 100% more effective as product managers. From a show of hands, there was some healthy skepticism in the room about this a realistic target. Although in 2001, I never thought my talented development team could achieve such gains either until we implemented Extreme Programming (XP).
So I think it is a fair to ask from where these gains will come. To be honest, I do not have a simple answer, but I do believe we have the collective knowledge in our product management community to tackle this challenge. I also have a few areas where I think we should start:
- Less documentation/more conversation – conversation is a deeper form of communication than documentation. It is a two way process that requires active engagement from both sides. Documentation is still essential but it should support communication and not be a replacement for the conversation. Further, anything documented that is not implemented is waste. Documentation detail should be added in proportion to the probability that the feature will be implemented.
- Time box research – Agile development teams use time boxed research projects when further understanding is needed to provide an accurate estimate of effort to develop a feature. Time boxing forces focus on the task at hand and contains the inquiry to gathering only enough detail to answer the question. Product managers should apply this technique when evaluating new markets, business opportunities, and product concepts.
- Work in small batches – When large batches of work are moved between departments (such as product management, development, and QA), feedback loops are delayed, quality is hurt, efficiency is decreased, and delays increase. (See Working in small batches). Limit the number of items being worked on within your product at any one time and move smaller chunks of value through the system faster. For example, instead of passing an entire product requirements document representing months of work to development, pass each feature as it is documented.
- Transparency – make it easy for your team, your co-workers, and management to know what you and your product team are working on, what is waiting to be worked on, and what is not going to be worked on in the foreseeable future. This can be done with a task board, wiki, or other collaboration tool. The more visible, the better. By making your work visible, you will spend less time updating peers on status, field less inbound questions, and make it easier for other to identify if you have overlooked something.
- Work as a team – Teams work together to achieve a collective goal. You and your product team need to be able to pitch in and help each other when needed. This might mean developing wire frames if your UX person is overloaded or assisting QA if they become overloaded. Likewise, it is ok for the team to assist in detailing a feature with your oversight if you become overcommitted. Keep the team focused on delivering regular value and work together to clear bottlenecks as they emerge.
- Test before you build – Test your product ideas prior to developing the product and throughout the development cycle to prove the concept and optimize the desirability of the product. Concept and prototype testing, AB tests for websites, and taking pre-orders are techniques to do this. By investing a little more effort upfront, you can save yourself rework trying to take a weak idea and make it right.
- Shared vision – Product Management is responsible for setting the product vision and aligning the product plan with the business strategy. Each release should be tied to clear, measurable outcomes (e.g reduce support calls by 10%, increase customer satisfaction by 15%, grow revenue by 20%, etc). By keeping outcomes front and center for the team, members will make better decisions and reduce their dependence on you as the product manager.
- Retrospectives – Product development teams have been using regular retrospectives to identify areas for improvement. Product management should adopt this practice. You can start by simply asking the same three simple questions “what’s working, what isn’t, and what should be changed” (Mike Cohn, www.mountaingoatsoftware.com) or conducting more rigorous root cause analysis as part of PDCA (plan, do, check, act) process. But do something at a regular interval. If we don’t focus on becoming more effective, we are unlikely to get there.
Have you uncovered new ways to be more effective? Please share your experiences with us.