Infrastructure Field of Dreams
We work with lots of clients on internal infrastructure and shared architecture projects – both from a product management/requirements and evaluating the software architecture itself. These projects tend to be major CTO-led efforts to [for instance] consolidate customer databases across divisions, build a shared corporate application for pricing and invoicing, or establish a common product catalog. By definition, this is a “big company” kind of initiative. Re-centralizing what’s drifted apart. Creating cross-divisional leverage.
In most cases, these projects run into trouble early (and often) because they fail to
treat their various business units as customers, and fail to aggressively market the features and benefits of shared infrastructure. We all know that prospects for our outside offerings need clear, repeated, persuasive communications and motivators to move them through the buying process… yet we ignore this experience when considering internal audiences. We build an Infrastructure Field of Dreams: “if we design it, they will come – and magically adopt it throughout our company.”
Here’s a generic version of story:
BigCorp has ten business units. A quick count shows at least eight different product catalogs – the databases that manage product numbers, details, descriptions and pricing plans. These diverse systems make it difficult to bundle products from different groups (“how do we include a trial subscription to our new “green gardening” magazine with each every lawn mower that we sell online?”) Pricing and sales reporting are done differently in each unit. Creating a company-wide online store is nearly impossible.
Looking through our “common infrastructure is better” glasses, it’s obvious that one (unified) product catalog would make life easier for everyone. So why do the majority of similar service-centralization projects fail to get the business unit support they need? Why does it take an extra year of cajoling and management escalations to get customer-facing product groups to adopt a company-wide process for account tracking, or invoicing, or standardization of pricing plans?
Where You Stand Depends on Where You Sit
If you are the product champion for new centralized services, you spend your days planning those services and identifying how the company will save money (or improve cross-business-unit effectiveness, or leverage its IP assets). You’ve mapped out a migration strategy, picked your early adopter groups, and helped the development team design a terrific replacement for various existing solutions. It’s completely clear to you (after months of study and acronym decryption) that a shared customer database (or whatever) is critical to the company’s health and success. Software Stockholm Syndrome.
Trade places, though, with your peers – the product managers and executives in the business units. They are focused on revenue and customers, not on internal systems. They have long lists of features for their development teams to chew through, and competitors who always appear more nimble. Their honest objections might read this way:
- They need all of their development cycles applied to their external customer requirements and their own product architectures. They don’t have time or attention to make infrastructure changes for you.
- Division-level operational systems may not be appropriate for the rest of the company, but meet their local needs very well, thank you. Each group’s pricing [or customer database or shipping or recruiting or customer satisfaction] system has grown up to handle their unique situation.
- The last few times, corporate IT’s simple upgrades and minor changes have been anything but simple or minor. Instead, hugely painful and frustrating. Your credibility is in short supply.
- Corporate’s solution seems 80% right for each group, but not 100% right for anyone.
- Most revenue-facing groups don’t perceive an urgent need for cross-business-unit coordination right now, so keep postponing implementation.
In other words, your business unit customers are not sold on the need for your new centralized solution. They are acting rationally by focusing on revenue customers and ignoring your offering. If you worked in Sales, your manager would refer to this as a promising account development opportunity.
Filling the Void
Just as we would for external customers, we will need a campaign to market and sell the (internal) improvements that our users should be excited to accept. We need to position, package and promote our new thing. If your company is willing to spend $5M on a new real-time customer tracking system, then spending $50k to drive adoption seems a bargain.
You’re unlikely to get a separate Product Marketing person assigned. So, assuming your project adds real value, plan to:
- Start an internal web page (wiki) for your project. Put all of your docs online where users can find them.
- Create a features/benefits list that resonates with the target users. Describe some revenue-related advantages that matter to your customers. (“With a central contracts database, you can close quarter-end deals twice as fast.”) Make sure these are supportable.
- Build a high-level workflow or “how to” that includes a timeline. Save yourself having to repeat this 400x.
- Set up an email alias to target users and their management. Send a short monthly update with progress, recap of benefits, links to key documents, and your email as the place to send questions.
- Invite key constituents to lunch. Get on their staff meeting agendas. You’ll get the straight scoop, and it’s harder for them to say “no” in person.
- Work like crazy to get one successful implementation, then showcase it. If you don’t create good buzz about your project, second-hand chatter may create a PR problem.
- Get t-shirts for users as well as the development team. Create an award for the fastest implementation. ($500 in marketing could save $500k in adoption delays.)
- Repeat. Then repeat some more. Marketers know that prospects ignore unwanted messages the first seven times.
You get the idea. Internal audiences need to be marketed to.
Carrot and Stick
But we know that cajoling isn’t enough. You will never get universal adoption of your
project without some downward pressure. If you’re a contributor-level product manager, someone above you needs to nurture and push and demand and posture on your behalf. If adoption and success are truly important to the company, the executive team should be considering:
- Mandates and deadlines. If you project lacks a formal mandate, you should consider a job in a revenue-producing unit.
- Business unit VPs as sponsors. If the guy (gal) who signs divisional paychecks says this is a priority, it’s likely to get done.
- Quarterly executive scorecards or progress reports. Does your CIO sit with the executive staff and review divisional adoption progress? Embarrassment leads to action.
- Levying a tax. Business units can opt out of corporate-wide solutions, but have to pay their share of the project costs. If this makes economic sense for too many divisions, you’ve designed the wrong shared solution.
- Bragging rights. Give the first two executive adopters trophies and weekend boondoggles. VPs will do bizarre things to upstage their peers.
And so on. You need strong long-term executive support to roll out infrastructure. Otherwise, you’re swimming against the current.
And if you’re an executive selling the ROI of improved infrastructure, you need to step up with the clout and extended attention that such projects demand. Plus a little budget for internal marketing.
Sound Byte
Product managers of internal systems need to promote, market and sell their solutions internally. It’s not enough to build systems that bring business units together: PMs must drive adoption on the ground as well as with executives. Don’t just build a Field of Dreams.
