Why is a mainframe product guy writing about innovation you ask? Actually, I am involved in more innovation since I moved the the mainframe than I was in the new-fangled world of distributed computing. The mainframe isn’t just about 3270 screens any more.
The work I am doing is primarily around the interaction between the other systems in the data center and the mainframe. We are developing solutions using Agile development practices which I am completely sold on. Rapid development, high customer engagement levels, self-directed teams, etc. have given me new faith in the ability for enterprises to deliver high quality products without the traditionally high overhead.
However, as we have brought these products to market I realize that many of the skills that we are honing in the development teams should be brought to bear as we prepare the field to take the products to market.
Agile go to Market Preparation
Before we jump in, let’s start with what motivates people to buy enterprise software. I remember Mark Lewis from EMC asserting that there are only three reasons:
I am a huge fan of this assertion; it keeps you focused on what is really important but note what is intentionally missing from the list…sex and sizzle, glitz and glam, shiny new stuff, etc. Consumer software often sells on this basis and it will get people in the enterprise to sit up and listen, it might get you through the customer’s door but it won’t get them to buy consistently and once the tarnish sets in, they will not be renewing contracts.
With innovative solutions you have to be able to deliver enough of a combination these three motivations to overcome the barrier to adoption. Note that customers typically see higher barriers to adoption for innovative solutions. Why?
Innovation = Disruption
A replacement solution or an add-on to an existing solution will typically be much more manageable than bringing in a truly innovative solution. In the short term, innovative will often beget new infrastructure, a learning curve, reassignment of resources, etc.. The results are often extremely worthwhile but someone needs to deal with the discomfort during the transition.
Practically what does this mean?
So, I took some time to develop a presentation on this topic looking at successes and challenges from some of the innovation that I have worked on over the past few years and came out with the following list:
Looks great, doesn’t it? No one can argue that these are all things that you need to focus on when taking innovative products to market but then one of my smarter colleagues pointed out that this list was just Product Management 101…I couldn’t really argue with that but with innovation it’s just a bit more important, difficult and requires a lot more discipline so we added this.
So, why is it different when you are looking at innovation rather than regular product development?
When you are innovating you are typically a lot more excited about getting the product out the door. You don’t want to wait for processes and validation...”everyone is going to love this, why wouldn’t they?”
This impatience is the driving force of a good team, everyone wants to succeed, they all want people to start using the product, they are drinking the Kool-Aid 16 hours a day. It’s easier just to move ahead and have ‘faith’ that it will all work out.
Balancing this blind enthusiasm and the discipline of understanding the customer problems that you are trying to solve is going to be the difference between success and failure.
IMHO, this is typically just an excuse rather than reality. There’s the fear that if anyone else finds out what we are doing then we won’t be first to market; that the competition will message ahead of us. This is all true, but as Mike Madden likes to remind me frequently, “there's never a right time to release the wrong product”.
If you can’t share what you are doing with at least a few customers then you’re taking quite a risk.
Lack of a Defined Market
This one is more real. When we released a “Cloud Backup for the Mainframe” product recently we were not entirely clear of the TAM – is it the $64 quadtrillion cloud storage market? Probably not. Is it the 5,000 mainframe customers worldwide? Sure. Now consider the segmented addressable market estimate based on the different cloud service levels available: who will tolerate public cloud, what about data residency concerns, bandwidth in different geos, etc. The addressable segment when tied to one technology is not always quite as clear.
However, you should take an educated and realistic guess and spend time looking at how much of the market segment you can address with each proposed product and/or release set.
Lack of Existing Customer Base
For some companies, this is a real problem. Without customers to call on under NDA, it can be difficult to validate your assumptions and pre-build a community of early adopters. That said, if you do not have access to customers during ideation and development then what makes you think that you will have some once you release the product? BTW, building a product in the hope that you’ll be acquired before you have to start to sell is not a great strategy.
So what should you do?
Engage with customers early in the process and stay engaged
- In Agile we engage with customers during development to validate the features in real time. For innovation, this level of engagement needs to start during the ideation phase, not just the development period.
- Don’t just validate your ideas – get real customer engagement. Do sprint reviews for the ideas as they solidify, present back to customers with a regular cadence; this gets them to ante up some of their valuable time not just “blind enthusiasm”
- If your customers are not willing to sign up and attend monthly reviews agree to take early drops then drill down and find out why. Be realistic – is the software really high value? The target should be to have customers ready to sign a PO and take the code into production the day that you go GA.
- Identify who you will be selling to in the organization. If you really are innovating then there’s a good chance that you’ll have to bring new people into the room. The CTO might have an interest, it might take a cross-discipline team to implement, etc. Open those doors early and create those relationships.
Give your sales team concrete information and have them test it early
- This is not easy when you are playing in a new space but it is essential. You HAVE to be able to show a customer that this solution really will pull sufficiently hard on one or more of the Make-Save-Liberate levers to offset the disruption.
- Make Money
- Your sales team have to be able to make a convincing case that the solution will help your customer to actually increase profitability. Arm them with the market analysis and financials that you’ve done and with references from the reference customers.
- Save Money
- You have to start this equation with real data about the current cost model. Then you work back from that to show that your solution will save XX% and have a YY month ROI period.
- In the spirit of Agile, don’t spend 6 months getting a massively complex model in place only to find that you missed the opportunity. Create a model based on ‘some’ real data and then refine this every time it is used. You might start with only 3 data points on to work from but you’ll build this up rapidly.
- Stay out of Jail
- I’d argue that fear is by far the most effective lever to pull…when you can. However, this is one area where you really do need to have subject matter experts in the process; you’d better understand the nuances of the regulations and risks if you are going to play this card.
- If you really don’t have concrete data then make an assertion to arm the sales with so they can at least start a conversation with a prospect – worst case, you will start to build out data and potential objections to address. Once armed with this – ask your sales team to commit to a quota for the product – this is the ultimate “bluff caller” for sales.
Train the sales team, get feedback, incorporate the feedback, rinse and repeat as necessary.
- If you can get a dedicate SWAT sales team who are (1) focused on the innovation technology and (2) only paid on the new solution then do this every time. It is costly because it is an overlay but it will speed up the sales processes by reducing barriers. Regardless, make sure that you have subject matter experts (SMEs) for the space you’re selling into. If they have a reputation in the space or come from a competitor in the space then all the better.
Provide a dynamic “objection handling” process.
- When a customer brings up an objection jump on it. Can it be addressed by agile engineering or not? If not then document the response and loop back to the sales team so they can proactively address it. Assess whether the customer is raising objections because they have a real issue or are just getting cold feet and looking for an out.
One softer aspect is the strategy for that product in relationship to your company or the market direction.
- There can be an advantage to being able to discuss how the innovation fits into a larger strategy for the market in general, how it fits into the customer’s company and how it fits into your vendor strategy.
- I’d say that generally this is not going to close a deal but NOT having it could easily stop a deal.
In all of these things create processes that can respond to change rapidly. Set expectations with the field that the message that you are giving them today WILL change as we get closer to releasing the product and that it will continue to change as we involve more customers.
The key to selling innovation is really no different to selling anything in the enterprise software space but the tolerance for missing the target is much lower.