Part 2: Are you buildng Products or Solutions?

This is the second of a two-part article

In part one of this article, I made the case that incentives hold back companies from creating products that work together. But, is it really that simple? Let us look at some issues and potential solutions.

Previously erected silos will prevent BU leaders from working together. Selling a solution is a lot harder than selling a product, so sales leaders won’t buy in. And unless there is strong leadership in product management, roadmaps will never be coordinated. Even if all of this happens, engineering managers may have to make the decision of putting in more time and effort to coordinate deliveries across products, which means they may not be able to meet previously committed dates.

This is where strong leadership and company culture matters a great deal. The ability to work across groups, communicate points of view, and obtain commitments from other teams to work together is critical to adopting a solution-first approach.

 Assuming the leadership commits to the solution-first approach, how would a company actually institutionalize this?

Here are a few steps:

1. Product management leadership defines the cross-product strategy and articulates why the solution(s) approach will be more valuable to customers. Key pieces of the strategy include the following:

·      An agreement to an approach for creating solutions as there are many ways to do this. For e.g. Will BigCo create a platform which must be the foundation for the different products?

·      What’s the there a budget and how is it implemented across the different BUs?

·      What is the joint sales and marketing strategy? How will these be sold and delivered?

·      What is the cross-department R&D plan? How will resources be shared?

·      How will the products be supported post roll-out?

2. Create a business case that shows the benefits of going to market as one solution instead of individual products – if the pie is bigger, there will be more appetite for BU leaders to adopt the solution-first approach

3. Create roadmaps that explicitly show the dependencies on other related products

4. Joint pricing, messaging, etc. are all worked on across the different marketing teams

5. Sales teams are educated to sell a solution vs a product, and the incentives are well understood

6. R&D managers understand the impact of other product’s delivery timelines and the roll-out of individual products is well coordinated. Future releases are planned and EOL discussions are determined taking into account the impact on all teams

7. A clear support plan is outlined and is in place prior to the release of the solution(s). This is not a trivial process – how will support route calls if there are multiple development teams and overlapping functionality?

In summary, going to market with a solution-first approach requires a clear understanding of the overall strategy across product lines, benefits for the customer, explicit commitment from leadership to making this a reality, and a clear understanding of the incentives for the various internal teams. 

Although we haven't solved every problem here, we can make great strides in ensuring our solutions' success. Without all of this in place, a solution-first culture will be very hard to implement. 

Do you see these issues as well? Do you agree with the solutions presented or do you have other feedback? Please feel free to leave a comment.

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.