Beyond DevOps

Over the last several years the DevOps movement has highlighted the need to break down silos between software development and operations. It emphasizes  communication, collaboration, integration, automation, and measurement of cooperation between software developers and other IT professionals[1]. When done right, it can help an organization rapidly produce software products and services and to improve operations performance. But while devOps focuses on breaking down silos between development and operations, in many organizations, big and small, the silos that remain between development and other parts of the business become obstacles for the business in achieving its true potential.

To build and sell a successful product or service, people need to be empowered with information needed to make the right decisions. Information needs to flow freely between various functions within an organization at all levels. This isn’t a new concept by any means and yet even today often communication happens at one level and information is partially shared with the broader organization. This can lead to poor decisions, surprises and delays, resulting in costs that can be easily avoided. The solution isn’t to communicate more often or have everybody attend every meeting and participate in every decision making, but rather to pick an organizational structure that is pertinent to the size and attitude of the people in the organization.

Recently I got into a discussion about organizational structure with Simon Wardley, researcher for CSC’s Leading edge Forum. Simon has written a few great posts on organizational structure – On structure and The only structure you will ever need for e.g. Rather than a departmental structure, a more effective approach is to break the organization into cells connected by services and comprised of people with skills required to provide the services e.g. engineering, product, finance, marketing, support, services. Cells have autonomy over how they organize and run themselves but autonomy is accompanied with accountability and measurement against specific criteria.

Its easy to see how a cell based approach to organizational structure is can lead to better outcomes. Yet it is not common and most organizations use departmental structures impeding their ability to compete effectively.


Customer Success or Customer Support or Both?

How are you improving your customer retention and lifetime value? If you are thinking better support, you are thinking about customers wrong.
Don’t get me wrong. If you are a product company of any kind, depending on your size, you need to have some one or an entire department dedicated to solving customer problems. Traditionally customer support departments have been focused on solving customer issues and escalations, answering customer queries for information or recording customer feature requests for product teams. While these activities are still needed to service customers, these are reactive tasks and may not help identify issues until its too late. 

On the other hand leveraging predictive analytics can help identify risks early on and provide proactive assistance to customers that may not reach out to customer support. Proactive assistance could easily take the form of an email offering help or providing a free trial or a 1:1 conversation with the customer on the phone or video. 

As an e.g. here is an email we received when we signed up for Blossom at Enstratius (Dell) when we were transitioning to weekly releases

“Since you are one of our Early Adopters we have a special offer for you.
A one hour free google hangout with our CEO & Head of Product on the Essence of Managing Software Projects.”

Since we were new to the process, we leveraged this offer and got several of our questions regarding process and best practices answered while also providing feedback to Blossom. Some our our pain points were rapidly addressed which increased our confidence in the team. 

Proactive assistance should leverage product usage data, metrics and funnel analysis to determine what the pain points are and how customers are using the product. Data should be tested This data helps frame the engagement with the customer for not only risks, but also opportunities for product improvements and for cross-selling and up-selling products and services. 

In short, the question is how are you are thinking about improving your customer relationship. Relabeling your customer support department as customer success will not cut it. You could create separate departments for customer support and customer success. Organization is not the point. Rethinking the approach is. 

The evolving Product Systems of Engagement and Record

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.

Systems for long 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.

Systems for short release cycles

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.

The Product Management Triange

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.

Data driven Product Management

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.