Friday, July 31, 2015

Part 1: Are you buildng Products or Solutions?



This is the first of a two-part article

How many times have we all heard the phrase ‘Go to market as one company, instead of multiple individual silos’? What does this phrase really mean, and why is it important?

In today’s application economy, many traditional ‘brick and mortar’ companies have application development departments bigger than even large software companies. Over time, many of these departments, including traditional software vendors, end up with multiple and even redundant software products in their portfolios. Now, this by itself is pretty normal, except typically these products may not be designed to work together, nor designed to solve a larger set of different but overlapping and related problems. This situation is particularly acute when the products span business-units.

The problem is both the company and their customers lose in these situations. The company misses out on potential cross-selling opportunities, while the customer does not get the best possible solution.

Here is a simple example that illustrates the problem and is applicable across all industries. Imagine a large retail bank, BigCo, which relies on its software products to track interactions with its customer base. Each channel that the customer uses to interact with the bank (think mobile banking, branches, ATMs etc.) may use a separate application or product, that manages a particular area. None of the applications share information with the other banking products, although they track the same customer. As a result, the bank never gets a full-picture of the customer’s needs. The bank misses out on cross-selling opportunities, and the customer loses out on potential services and benefits that the bank may be willing to share otherwise.

Further, from the customer’s perspective, the usability features of the individual products or applications may all be very different, leading to a poor user experience. The marketing collateral for the customer may be disjointed and limited in its ability to communicate the true value of the solution(s).

In many cases, particularly when customers are corporations themselves, they may receive multiple calls from a software vendor’s sales teams, from different BUs, all pitching their individual products, effectively competing with each other. In these situations, one cannot blame the customer for assuming that the software company/department simply doesn’t have its act together.

While almost comical in the absurdity of this situation, in reality this is a hard problem to solve for BigCo, and it spans UX, engineering, marketing, and sales departments among others.

If we were to headline this problem, and generalize it across all kinds of industries and companies, it would likely read something like this:
How should an application development group / a software company coordinate the efforts of its various teams to ensure all of its products and services have a similar look and feel, interoperate with one another and share data, while having a coherent pricing model and a coordinated go-to-market approach? Can a company have a solution-first approach to releasing products?

Root Causes

Let us look at some reasons why companies may not be able to solve this issue easily.
1.     Is this a structural issue? Are there lines drawn between teams which prevent coordination?
2.     Lack of knowledge? Is it because the various teams do not know they need to coordinate with one another before releasing a product and have joint roadmaps?
3.     Could it be an incentive issue? No incentives for BU leaders to work together?
4.     Timelines and deadlines preventing effective collaboration?
5.     Is it a leadership issue?

In my experience, it is all of the above, but the most significant obstacle to a coordinated product release cycle, where the products are all designed to work together, is a lack of incentive. BU leaders are evaluated on the basis of their individual P&Ls. Sales teams are commissioned on their individual quotas. UX and engineering teams are driven by deadlines for their own products. Who has the time to worry about other products when the incentives don’t line up?

The obvious solution to this conundrum seems to be to fix the incentive problem, which is to tie a team’s success to the success of the overall solution. But, this is not as easy as it sounds. The next part of this article will focus on some solutions.

Have you encountered these issues? Please feel free to leave a comment.

No comments:

Post a Comment