Promoting adoption of internal software products
And now, you’ve kicked-off your in-house, non-revenue-generating product. This could be a pipeline infrastructure that deploys all your products. This could be a design system owned by a user experience organization. Your stakeholders ask about your roadmap for internal adoption by other teams. You likely have a shared role, maybe you are a design manager or an engineering manager tasked with adoption– you could be a technical program manager (TPM) or involved in DevOps or DesignOps. Even if you are internal-only and your consumers are not paying customers you still have to have a go-to-market strategy. The following questions will guide you on your path forward.
The project part
What market are you in?
The first concept to understand is what type of market your product is “sold” in. Your go-to–market strategy differs whether your market definition is a single known paying customer or a segmented mass market customer. Knowing your target market will also prevent you from comparing yourself to others.
The following are markets listed smaller to larger:
Contract development
Oligopsony (a few known customers)
Niche software
Mass market (direct-to-consumer marketing-lead)
Mass market (sales-team-led, “enterprise”)
Markets for internal-only infrastructure products are called oligopsony. You have a few known customers. You know their names and have access to all their Slack channels. Due to the fact that they work at the same company as you, they have some goals in common with you, even though they are not paying customers. And, most importantly, they are crucial to your success!
Ask what features to add
The second concept to understand is how to best serve your few known customers. Knowing how to serve your customers will greatly contribute to creating alignment and shared success.
The happy-path is defined. Have we minimized decisions about our most popular features? What is the happy path for product enablement, for example? Does this happy-path have a documented and shared version?
Problem areas are defined. Where could your customers get stuck? On what forum or channel do your customers ask questions?
The on-boarding experience is clear. Could you make any documentation changes that would increase adoption?
Consistency. Is your documentation and product consistent and intuitive? Is it easy-to-use and predictable?
Think long term
It is also important to understand how to think long term. Having listened to your customers and walked a mile in their shoes, the next step is to align your organization to move forward together. Here are a few ways to get long-term alignment:
Identify "big wins." What exciting new services can we (and our partners) now build? Take advantage of others’ successes and use cases. Is there a big product launch or company level OKRs (Objectives and Key Results) that can increase adoption?
Define adoption metrics/competition. Can we serve new consumers and new products? How do we promote adoption?
Extracting value. Are we aligned with the organization's important products? Do we help them deliver?
Sustainable benefits. Can consumers get extra value from an upgrade without modification?
Defend and expand
Know how to defend your product and show its value.
Define return on investment. Decide if this program is sufficiently relevant to justify the resources and effort it will consume. What is the ROI? Is it worth paying for–at the executive level?
Define value. How does this identify (or invent) value for cooperating business units? Can we quantify what is saved?
Define incentives. You should create carrot-and-stick escalations. You should incentivise and recognize early adopters.
Evangelize. Arrange informal engineer-to-engineer meetings to promote the program’s technical merits.
Are you the only option?
With enough executive leadership buy-in you could require adoption, but otherwise you will need to use your influence and storytelling to champion adoption. There’s a million things on every product team’s backlog and you can’t just waltz in and insert your priorities. When employees choose whether to use an internal system, you may need to present a rather convincing strategy for your consumers.
Be the default. Success for these systems depends, in large part, on getting folks to use them consistently. Being the only choice can be helpful, but don’t let it go to your head.
Focus on the end-user. Ability to describe clear benefits to the individual consumer (not just the company), and get the word out. Does this make their job easier?
Target evangelists. Identify stakeholder delegates (functional or product leadership) who will be responsible for ongoing evangelism, employee reminders, contests, and other ways to encourage participation. People trust this person. Do they trust you?
Plan out releases. Do you have a sustaining-engineering plan, since no project is ever truly finished or bug-free? What problem are you solving for them? What will they get for free if they join you?
Plan out EOL. An end-of-life plan (no matter how unpopular!) for any approach you are replacing is needed, with backing from management, so that late-adopters will eventually have to get on board. This enables you to stop supporting the old solution and creates leverage to motivate folks to adopt the updated product.
The people part
Who owns this platform product? Putting together "platform teams" is not straightforward. From a business perspective, they make hardly any sense. Why would you have 20% of your engineers (or other functions) not focused on features your customers may not see? In addition, why would you have your most senior engineers work on these efforts?
This question is very often the reaction from the business side of the organization to the idea of funding a platform team. In small organizations platform teams do not make sense.
Platform teams improve organizational efficiency. They reduce work duplication and help standardize approaches. For example, setting up a security team can help standardize security vulnerability checks across your company.
When a platform team succeeds, duplication of work is reduced. Platform teams want to onboard customers who benefit from their services. This allows product teams to spend more effort focusing on their end-user features, but it also results in Platforms becoming more flexible and better at serving more customers.
Platform teams are essential when scaling up and scaling fast. When you’ve crossed the line of 50 engineers, and you’re in a business that is growing rapidly in customers, products, complexity, platform teams make a huge difference.
Platform teams own non-functional requirements like system reliability, the ability to handle more load, or the ability to support more products, in a way that satisfies non-functional constraints.
Non-functional constraints are all the invisible things that are critical to any product's operate, but they may not be a feature that your end-use customers want and know they want. These include:
Security and data vulnerabilities
Compliance and accessibility conformance
Reliability and availability
Latency and performance
Non-functional constraints (memory usage, footprint, etc.)
Developer experience (CI pipeline, user experience tooling, shared user interface components libraries)
The more complex an organization becomes, the more sense it makes for dedicated teams to own these non-functional parts and ensure all teams adhere to the same requirements.
Product platform teams are just as critical for scaling as infrastructure-like platform teams are. As a product area grows and splits into multiple product teams, it often makes sense to move common functionality and services to a product platform team of its own.
Platform pain points to keep in mind
Platform teams bring their own pain points. There is no doubt about how helpful platform teams can be, but they also present a number of challenges. Here are some:
It’s harder to measure your goals. Measuring the impact of an internal product on the bottom line can be more challenging than an end-user-facing product. External-facing product teams always have goals tied to business metrics such as keeping paying customers happy or pursuing a potential buyer. This is not the case with platform teams. Furthermore, platform teams move the needle slower, so feedback on their goals is slower than end-user oriented product teams.
Low lines of direct communication with end-use customers. Platform teams can sometimes build a feature they expect customers to want. However, it may frustrate customers who did not want the feature, nor the additional work it entails. Keeping an open loop with end-use customers is a major challenge for any newly formed platform team.
Working on projects the Platform team wants instead of what customers want. Platform teams need to balance building things that internal customers don’t ask for, versus what they do. For example, a platform team will want to invest reliably and keep tech debt at bay. However, it will also need to add features and capabilities relevant to customer-facing teams. However, there’s a danger that the Platform team overprioritizes the work they deem important–even to the point of breaking customer teams.
Seniority saturation. Platform teams work across many engineering teams and often have company-wide impacts. Working on such teams, engineers also rarely have to deal with business stakeholders; a platform team’s direct customers are product teams after all. This setup sounds like paradise to many senior and above engineers. However, platform teams can get over-saturated with senior people seeking to avoid the business-side and create “perfection.” This risk can make professional growth difficult for some team members.
What questions do you ask when leading an internal non-revenue generating product?
Additional Reading
Interested in running a platform team or product? I recommend reading:
Charity Majors’s 10 Platform Commandments
The Pragmatic Engineer's The Platform and Program Split at Uber
Digital Platform Strategy from Thoughtworks
Adopting a digital platform strategy: an iterative approach from Thoughworks
You’ve got a new project at your tech company, but you’d like it to be a full-blown internal product that all your company’s customer-facing products adopt. [7 min read]
