Random Acts of Architecture

Tales of an architect trying to bring order to the chaos that is modern information technology.

Tag Archives: Product Management

The Future of Product Management in Enterprise Software

PM Challenges

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.

Who Needs a Software Architect?

Small teams of senior people working on a well understood problems with known tools and little integration or dependencies on other applications do not need architects. This covers a significant proportion of line of business applications written today. However, there comes a point where cracks appear. There is no well understood threshold for a team size or a product’s complexity to require a software architect – no two individuals, teams, products or deadlines are the same, so what works well for one may not work for the other. However, there are four indicators or “smells” that a software architect is needed.

First, the product either lacks or does not meet non-functional requirements such as scalability, performance or security. Product Managers (PMs) or other customer advocates rarely articulate such requirements and, when they do, usually articulate them poorly or give them too low a priority. A software architect can balance the customer or business requirements with technical ones and provide the technical foundation to meet the customer requirements.

Second, the product lacks technical vision. Enterprise applications rarely exist in a vacuum. They need to integrate with other applications, often share components and need to lay the foundation to make likely future changes easier. Useful new components, frameworks or libraries may become available that allow the team to focus on business value and not solved problems, especially for older products (i.e. 10 years+). The industry may trend toward different platforms (e.g. mobile) or business models (e.g. cloud). Development teams are often too focused on the current release of the current product to take a step back and few others have the technical knowledge required, unlike a software architect.

Third, the development group has poor interteam communication and collaboration. Effective communication is easy for small teams of three to five people. This is much harder if the group has several hundred members in different continents and time zones. Effective cross team management may be difficult because individual team leads are usually focused on their own teams and the common management point may be a director or even an executive who has bigger problems on his or her mind and lacks the required technical focus. A software architect can divide the work and act as a coordinator between teams.

Communication with development teams outside the group is also critical. A development group often needs someone with broad rather than deep knowledge to evangelize their product(s) or identify integration points or sharable code. Once again, team leaders are usually too focused on their teams,  directors are often too removed from the technical details and individual developers find the higher, longer term views too distant from actual code. A software architect usually has better communication skills, the right breadth of product knowledge and understands its technical vision. Similarly, non-technical but development-related teams like user interface designers, documentation writers or localization require someone with a broad technical knowledge and a customer focus.

Fourth, the group has unclear requirements or problem domains. Relatively few teams boast many subject matter experts or developers that use their software like their customers, particularly in junior teams, remote teams or those with a high turnover. PMs are often focused on dealing with customers or support issues rather than communicating detailed requirements to every developer. They also may not understand what the developers do not know and so provide too little or too detailed information. This process is also ongoing due to turn over and changing market conditions. Lastly, requirements also change as the project progresses, whether due to changing customer requirements, competitive landscape or just learning more about the problem.

These are traditionally areas where business analysts (BA) rather than software architects are used and can be used in tandem with a software architect. However, one exception is where business requirements may have unclear technical ramifications and feasibility, such a compliance with industry standards or regulations. Federal Information Process Standard (FIPS) 140-2 or Common Criteria require changes and documentation at many levels of detail which an architect is better suited to than a BA.

Note that software architects do not solve all problems with development. In particular, they highlight or exacerbate political or organizational problems when they try to bring stakeholders together or reconcile conflicting decisions and requirements. This may be intentional (to drive change) but is not sustainable in the long term.

%d bloggers like this: