Random Acts of Architecture

In traditional enterprise software, product managers represent the customer to software development teams. They draw on industry experience to propose and prioritize features, usually as the scrum product owner. They liaise between development and the rest of the business, particularly marketing and sales.

However the product management role has three main challenges. The first challenge is new business models, particularly the move from on premise software to the cloud.

Cloud software presents increased non-functional challenges. For example, cloud systems are expected to scale up further than on premise software. The burden of service level agreements (SLAs), upgrades, patching and backup/restore is on the vendor and not the customer. Cloud systems are usually Internet accessible, missing the protection of an organization’s perimeter security measures like firewalls. Multi-tenant systems and resource pooling mean quality issues and downtime can affect many or all customers and not one.

Where product management previously dictated product direction, product management now share responsibility with architects (enterprise, solution, infrastructure and application) and business analysts (responsible for internal business processes). While IT commoditization has made IT cheaper and more accessible, capable technical people are still required, albeit with a different skill set. The increasing emphasis on integration, such as exposing web service APIs to third parties, and multiple platforms, such as mobile and tablet, exacerbates this.

However, this gives a product manager more opportunities. With the move from capital expenditure (initial purchase + support) to operational expenditure (monthly charge), many organizations are liberated from a fixed purchasing cycle. Unburdened by the three to six month customer upgrade period, releases can be as frequent as the development team can accommodate. Product managers can offload technical problems rather than shoulder the responsibility of the whole product.

The second challenge confronting product management is the increasing use of analytics and metrics. Many industries, such as media, have been using analytics and metrics for some time but many traditional enterprise market segments are only now getting access to accurate usage information. For example, few organizations previously consented to on premise products sending usage data back to the vendor.

Many product managers rely on experience or recent customer conversations to make decisions. However, the on-demand provisioning, self-service and customer customization (as opposed to vendor customization) aspects of cloud products reduce customer contact. Analytics and metrics can help fill this gap but it is a different type of customer relationship.

Moreover, the quality and quantity of decision-impacting data is increasing. Tools and expertise to extract useful information are becoming cheaper and more prevalent. Intuition and experience are always useful but will be more focused to what metrics to gather and interpreting them. Decisions will have a grounding (or at least a rationalization) in data. Making a decision solely on a “gut feeling” will be less acceptable.

Also note that good analytics and metrics can easily be applied to tactical problems like improving a user interface or prioritizing between two features based on actual use. It is harder to apply analytics and metrics to strategic questions like market direction or new product acceptance. This is where product management insight will be most valuable.

Metrics also help mitigate the “squeaky wheel” effect, where vocal customers monopolize product management time and the product backlog. For example, it is easier for a product manager to dissuade a customer demanding improvements to a certain feature with evidence the feature is rarely used.

The third challenge is the rapid change. Many product managers come from a business role. For example, an HR application product manager may previously been a manager in HR. Others have come from customer-facing technical roles like support, QA or sales engineering.

Unfortunately, in some industries previous industry experience is quickly outdated. While product management’s customer-focused perspective is vital, being removed from the industry can quickly atrophy understanding of customer processes and priorities. Exposure to their own software product(s) and current organization threatens to limit their thinking to what is probable, not what is ideal.

This is particularly important for product managers that come from customer-facing technical roles. They usually come to product management with specific product improvements in mind but, once these are in the product, may be at a loss.

Instead, a product manager needs to build ways to learn and predict industry changes – developing a new feature often takes months and the feature must be competitive when it is released, not just today. This could be key customers, industry contacts, thought leaders, peers at competitors or industry press. Building personal relationships, such as at conferences and industry meet-ups, is crucial.

Moreover, many information sources available to product management, like metrics or competitor analysis, are available to others in the software development team. It is these alternate information sources and relationships that will differentiate a good product manager.

Product management can no longer horde this information. For example, architects need accurate customer usage predictions for scalability planning and infrastructure provisioning. Management needs to allocate staff. Operations needs to ensure they are looking for likely threats or issues. By the time these are included in a release’s requirements or a sale occurs, it may be too late. Hording assumes product managers are the only ones making strategic decisions. Product managers are often poor conduits for technical requirements, too.

Meanwhile, product managers have less available time. They are dragged into sales opportunities to demonstrate or demand commitment, support calls to placate unhappy customers and marketing for feature commitments. Agile software development methodologies, like scrum, involve the product manager more frequently. This creates a “red queen” effect, where product managers spend a lot of their energy merely keeping pace with the industry, competition and own products.

Product management has always been a challenging role – often all responsibility and no authority. While many technical people incorrectly equate product knowledge with industry knowledge, prior experience and a customer perspective are no longer sufficient to be a good product manager. Successful product managers will adapt to the new business models (e.g. cloud) and leverage the new tools (e.g. analytics and metrics) to be more effective. In the future, those that rely on outdated experience and intuition are likely to fail while those that learn and adapt quickly will succeed.

Indeed, the end goal of product management is to impart customer perspective and industry knowledge. There will always be a place for a coordinating customer voice but it will lead by teaching, not a requirements document. Those involved in development should not need to consult product managers for every new feature or for a customer perspective – product management should have already taught them to think like a customer.