In an earlier post, we laid out a framework for agile software development projects (internally consumed vs. revenue customers; single customer vs. mass market) in order to identify product-manager-ish skills needed by our product owners. We also walked through the model for revenue software projects.
In this second of three posts, we’ll look first at internally consumed software and then at the squishy intermediate case of software-enabled services.
Operational, Non-Revenue Apps
I classify a project/program as “internally consumed software” if it doesn’t generate revenue for the company; its primary users are employees or internal systems; and it meets non-strategic operational needs. This might include expense reporting (except at American Express, which sells such a service), resumé scanning (except at Korn Ferry), shipment tracking (except at FedEx) and document access control (except at the NSA). See “What’s Your Strategic App?”
Often, the development team is called “Information Technology” or “Technical Services” rather than “product development” or “R&D.” That’s a clear indicator that the revenue side of the company is not involved.
I’ve relabeled our horizontal access to be more relevant, since internal software has no mass market – but can have many consuming groups with different needs and priorities.
Laying Out Some Project Types
As we did with revenue software, let’s situate different kinds of projects along the internal customer spectrum:
Customer Divergence for Internally Consumed Software
[1] Our ideal project has users in a single department, with an executive sponsor who manages that group, and direct business value. “As the head of online technical support, I need my support engineers to have more powerful keyword search/index in our support database, so that my team can quickly find work-arounds from similar cases. Speeding this up 20% would save our department $500k next year. I’m assigning my best Senior Support Engineer to work with the product owner/technical team and find a solution. And anyone on my Support team who doesn’t want to use the improved system can transfer out.”
This is as good as any internal project gets. As long as a solution doesn’t cost more than about $100k, and the designated SME thoughtfully represents similar users, we’re on track. Our simple scenario assumes, BTW, that someone has penciled out the business justification. Most likely, our sponsor estimated the savings for her own department, lobbied the IT Director, and submitted various Finance documents in triplicate. And can insist that her Support Engineers switch to the new solution.
AFAIK, all intro product owner workshops/books assume this best-case situation: clear alignment of sponsors and users, obvious internal cost savings, willing subject matter experts, clear budget authority and rational delivery expectations. Would that it were always so.
[2] Things get a little more complicated when employees can choose whether to use an internal system. For instance, a new expense reporting app feeds directly into Finance, reduces manual data entry, and gets reimbursement checks to employees faster — but only for employees who find it/install it/ learn it/use it. (We’re likely to continue accepting the old Excel template and photocopied receipts from late adopters and sales people.) Or HR’s new health benefits sign-up intranet. Or our innovation initiative tied to a Jive/Yammer/Chatter/SocialText site.
Success for these systems depends, in large part, on getting folks to use them consistently. And one ghost-written email from the CEO is not enough. So some product manager-ish skills that these product owners should have:
+ Ability to describe clear benefits to the individual user (not just the company), and get the word out
+ Identification of stakeholder delegates (in HR, Finance, etc.) who will be responsible for ongoing evangelism, employee reminders, contests, and other ways to encourage participation
+ A sustaining engineering plan, since no app is ever really finished or bug-free
+ An end-of-life plan (no matter how unpopular!) for the old approach, with backing from management, so that late-adopters will eventually have to get on board. Which lets us stop supporting the old solution.
Delivering good software is not, by itself, a success. The payback comes from using that software. Product owners need to think a bit like a consumer marketers.
When systems involve behavior changes from multiple departments or functions, project risks are increasingly high. As David Taber explains in “Salesforce.com Secrets of Success,” moving to a new CRM solution demands serious coordination and incentives for users who aren’t very interested in participating. His sage advice:
- Don’t get every department on the system at once. Start with a small core, and spread it out to other groups incrementally as you gain confidence in the system and build user enthusiasm.
- The data is more valuable (and expensive) than the system it resides in. Code and functionality don’t matter if the data is rubbish, so focus on accurate info and easy access/updates.
- Avoid big bangs. Plan for several rounds of technical adjustments as early users shake down the new system. Set up an agile backlog to prioritize ongoing enhancements.
So these large deployment add more product management skills to the mix:
+ Endlessly communicating the benefits to individual users of the new application
+ Designing financial incentives/ penalties that drive participation
+ Sequencing roll-outs to produce early wins and positive internal publicity
+ Relentlessly highlighting company-wide objectives so that executives don’t thoughtlessly cancel mid-stream
Don’t plan on moving to another project for several quarters after initial deployment.
Demand for Product-Manager-Ness Among Internal Software Projects
Finally, [3] includes centralized technology organizations trying to standardize applications among far-flung business units. I’ve seen a dozen of these “common ground” or “shared infrastructure” efforts flounder, because they fail to anticipate the diverse needs/priorities of their “customer” business units.
I spent a year on such a project at Yahoo! We needed to standardize the retrieval of user profiles (“get this user’s nickname, location, age, gender and photo”) companywide, to meet legal and technical requirements. But more than 50 business units each had their own development roadmaps, priorities and resource commitments. Shopping.yahoo.com was adding capacity for the holidays; FantasySports.yahoo.com was implementing new player draft mechanics for the upcoming baseball season; Movies.yahoo.com was designing joint promotions with a major film studio, and so on. My infrastructure upgrade had to pull developers in 50 business units away from their revenue-generating work, and delivered no immediate product-level benefits. You can imagine the delays, escalations, cajoling, and re-re-rescheduled design meetings.
A product owner driving such company-wide infrastructure needs extensive internal marketing and political skills to:
+ Decide if this program is sufficiently important to justify all of the resources and effort it will consume
+ Identify (or invent) value for cooperating business units
+ Create carrot-and-stick escalations, with incentives and executive recognition for early adopters
+ Arrange informal engineer-to-engineer meetings to promote the program’s technical merits
This look suspiciously like the enterprise selling model for high-end commercial software.
Software-Enabled Service: A Fuzzy Middle Ground
If you’re a product owner working on core technology for your company’s key services – but not packaging up software for direct sale – product challenges are more like revenue product than internally consumed software. Plotting a few points:
Demand for Product-Manager-Ness On Strategic Service-Enabling Software
[1] Fundamental technical architecture. Most businesses are increasingly technology-based. If your team at FedEx or UPS (for instance) can dramatically improve package tracking accuracy, this will have implications for a wide range of products and services. Mobile apps will need to be updated; service guarantees reviewed; database polling sped up; marketing claims inflated. The product owner for a critical internal technology wants to be thinking like a commercial API-based service (e.g. Amazon Web Services). This calls for skills similar to architects or cloud product managers:
+ Identifying big wins. What exciting new services that we (and our partners) can build?
+ Finding new ways to define competition. Can we serve new kinds of devices, or show value in 10x faster updates, or reduce resources by 70%?
+ Extracting value. Where we should be able to raise prices (and who are the product managers for those service elements)?
+ Planning for backward compatibility. Can our hundreds of consuming apps get extra value without being modified?
[2] Visible feature-level improvements. Software embodies your service, even though you’re charging for something else. For example… if you’re responsible for portions of an online stock trading service, then most changes are customer-visible and customer-relevant. You should be asking questions like:
+ Have we minimized clicks and decisions for our most popular transaction? For instance, there should be a “happy path” for easily buying US stocks.
+ Where are users getting stuck? Where do they click HELP, call customer support, abandon transactions or loop back through?
+ Should a website change drive additional revenue transaction? And by how much? For instance, better research reports about International bonds should encourage investors to buy some.
+ Is my information consistent? The iPhone app, web page, customer support phone system and monthly statement should deliver exactly the same data.
Summarizing This Second Post
Previously, we considered various revenue products and the product-management-ish skills that a product owner might need. Here, we’ve unpacked some internally consumed applications and noted that more complex internal audiences (voluntary users and unwilling business units) complicate the product owner’s problem – and call for market-style skills in addition to agile experience. Software-enabled services turn out to look a lot like revenue software.
The last post in this series will summarize product management skills that a product owner needs when moving “up and to the right” toward mass-market commercial software. And consider how we find – or grow – such skills.