There was a time when product release cycles spanned several months. In this world, Product Managers created a PRD and when approved by various stake holders, entered it as an artifact in the system of record. The Engineering team would then take these requirements and create Epics, Stories and Tasks in their System of Engagement to manage deliverables for a release. If the organization has effective systems and tools in place, a Product Manager’s System of Engagement where he/she tracks feature requests is the same as Engineering’s System of Engagement and requirements are already available to Engineering as Epics and prioritized for releases.
As an example when our release cycles were 2-3 month long, we tracked feature requests as Epics in in a bug and feature tracking system Fogbugz When we planned releases we marked feature requests we wanted to get done in particular releases using a custom field in Fogbugz called Release. As we were also tracking bugs in Fogbugz, we marked bugs that needed to get into a release using the same Release field. This helped us easily view what needed to get done in a particular release.
Over the past few years businesses have started incorporating continuous delivery in their software development process to rapidly, reliably and repeatedly deliver enhancements and bug fixes to customers at low risk and with minimal manual overhead. Amazon and Facebook for example release to production multiple times a day. While the systems of engagement and systems of record used in the past can certainly work, new systems can enable the product development team to better plan and manage short release cycles.
As we transitioned to a 1 week release cycle from a 2-3 month release cycle, we started managing our product backlog on a month-month basis. We set meaningful goals for each month by identifying Objectives and Key Results for the month. While estimates are hard and almost always inaccurate, breaking down stories into tasks and reducing both, the number of tasks to be estimated and the timeframe, we had a reasonable idea about what we were going to be able to accomplish in a given month. We managed expectations by assigning a confidence level to tasks to signal which tasks we know we can deliver in a given week vs which tasks we may be able to deliver. We transferred the near term backlog to a Kanban board called Blossom and added both features and bugs that would take over an hour to fix to the board. This helped us easily visualize our work and progress and quickly and focus on resolving blockers. Our system of record became our bug tracking system where we tracked incoming feature requests and bugs while our system of engagement became our Kanban board where we visualized our prioritized backlog and tasks in progress. This is a relatively new process for us and we are looking to learn and improvise.
In conclusion: As release cycles get shorter Product Managers need to adopt systems of record and systems of engagement that enable them manage short term priorities so that over the long term objectives are met with key results. The right systems allow higher agility and productivity.
In order for a product to be successful, a company must design, build, test and market the product effectively and a Product Manager leads or facilitates various activities to achieve that. Thus on a daily basis the Product Manager must deal with the the triangle of forces that is People, Process and Technology.
A Product Manager needs to work with customers, development, design, operations, customer support, sales and marketing, company executives and industry analysts on a regular basis to define product requirements, prioritize them, ensure product quality, listen for feedback and communicate current product information and future vision. Each group requires a different communication style and a Product Manager must master the art of effective communication with each group. Often a Product Manager needs to negotiate product priorities with customers and sales or process with engineering, operations and support. Strong Negotiation skills can be of great benefit in resolving any differences that arise.
A Product Manager needs to have a process that allows information to flow from the market to the company and back to the market. Having a well defined process and leveraging effective tools allow a Product Manager to first transform market and customer data into a prioritized backlog for engineering and secondly transform the key results delivered by engineering into marketing and sales messages that can be communicated back to the market and customers. Tools chosen must not define the process, but rather the process must define the tools that are selected.
It goes without saying that a Product Manager deeply understands his or her product and the technology it leverages. However, in addition the product manager must be aware of various technological trends that the product may be able to leverage to solve existing problems faster or solve new problems. Understanding technological trends and exploiting key trends in a product can help the company stay ahead of customer needs as well as competition.
The benefits of Data-driven decision making have been long known. In 2012 a study from the MIT Center for Digital Business found that organizations driven most by data-based decision making had 4% higher productivity rates and 6% higher profits. Thus arises the need to develop and cultivate data-driven product management which values product decisions that can be backed up with data.
Today its more easier than ever to extract product data, whether its from web analytics tools, API analytics tools, bug tracking tools or customer service tools. Each of these tools themselves have APIs and data from these tools can be extracted and correlated to identify trends. With all of this data available at our fingertips it becomes easy for us to make informed and better product decisions.
One of the many but most important question that product managers need to think about and answer with this data is where is the money? There are two part to this question – What about the product makes customers open up their wallets and what makes them walk away. In other words, what is working and what is not.
Measuring whats working can begin with identifying the most used features in the product. Once we know what customers use most of the time, a percentage of product development can be spent on nurturing those features – making the user experience better and fixing bugs. This helps in keeping current customers happy and attracting new ones who may find these features beneficial as well. On the other hand, measuring what isn’t working isn’t as simple as identifying the features that customers are not using, although eliminating the most unused features can help simplify the product and improve user experience. A better approach is conducting a Funnel analysis to identify where the roadblocks are and what isn’t working. If we identify where we are losing customers, we can begin to address their concerns and capture lost opportunities.