White Paper Product Thinking Internal Product Management
White Paper Product Thinking Internal Product Management
White Paper Product Thinking Internal Product Management
White Paper
Product Thinking
When delivering internal products (platforms,
packaged software, hardware) to your business
Here's how they might escape… with a product thinking mindset shift.
But product thinking isn't often applied to the internal products in an organization – products and platforms that
solve real business problems and provide real value for your internal stakeholders.
What's more, by default, internal products are often managed by IT teams – as part of a large estate of applications.
And, IT teams typically apply their existing operating model to hit project-related delivery objectives – rather
than driving the roadmaps and strategies you need to maximize business outcomes and value. They are seen
as a cost center, not a source of strategic value.
This is important, as although your customer-facing products generate revenue, it's your internal products that
underpin business success.
How do you proactively manage internal products to provide a sustainable service to the business? So, moving
away from just delivering something on time to thinking about the whole life cycle.
How do you achieve a more commercial focus that drives business success and saves money? The answer
includes moving from a 'project' mindset of one-off solutions to a 'product thinking' mindset.
How can you change the focus from output-driven (i.e., when will the next feature be ready?) to outcome-driven,
where you help internal stakeholders realize the maximum business value?
How can you take on more of a leadership role to add value to the business? Of course, you need to respond
tactically to short-term needs, but you also need a longer-term strategic view as the company develops.
This white paper helps you explore what this can mean in your business.
Many outside of technology have a simple understanding that a 'product' is something tangible (something you
can hold in your hand). But this definition is quite limiting and doesn’t work well when thinking about most IT
products – after all, you can't 'touch' software. And many companies sell Software as a Service (SaaS) products.
A more useful description is that a product is something that can be delivered multiple times without having to
build from scratch each time. It multiplies the value of a delivery – its adoption can scale up without needing
to build something new for each user. Therefore, the original development cost is spread over all the product's
users.
This doesn't imply that products are unchanging. Indeed, it is likely that the product will evolve to support
different types of users – or different usage scenarios.
It is also likely that the product will be augmented with add-ons and configuration options, which means that it
better suits customers' needs.
The product itself might be hardware, software, or professional services. And it might be built in-house or
sourced from a third-party. Sometimes, it can be a combination of all these things.
In many organizations, ownership and management of 'internal products' has been down to the expertise and
diligence of IT. Although capable and willing, many have lacked the insights, tools, and approaches to make this
management effective. Indeed, they may also be restricted by the IT operating model. Other organizations have
product managers in place to manage both external customer facing product and internal products.
Table: Examples of external and internal products for a supermarket's technology portfolio
Typically managed
Used by Example Products
by
Supplier Management,
Inventory Management,
Employees, Delivery IT, Development
(employee use of
Internal Products Partners, Inventory or internal Product
e-commerce platform),
Suppliers Managers
scanner and receipt printing
hardware, laptops
For example, the internal platforms that underpin the products sold to external customers, such as an e-commerce
platform or billing system.
Software services aimed at particular business functions, e.g., Enterprise Resource Planning (ERP) systems like
SAP or financial management systems like Sage. Or generic 3rd-party products like laptops or mobile phones.
Some will be custom-built or adapted (which means there will be development work), others configured for the
business, and others adopted as they are.
Even though they don't directly generate revenue, they are often critical to the business and, if not appropriately
managed, can frustrate plans and impact profitability.
Internal users are often treated as second-class citizens. They may have to deal with a terrible user experience,
and no one thinks it's a priority to improve things. But, although the system works at some level, the overheads
and operational inefficiencies created can raise huge hidden costs. Sometimes, whole jobs are dedicated to
copying and pasting data from excel spreadsheets into antiquated systems.
It recognizes that someone must take a balanced, objective view across the organization – and think about
the cumulative impact of all internal customer requests. Additionally, they must consider the impact on existing
technology infrastructure and long-term support.
Strategic
• what gives the most significant benefit to the The product
business approach
• what are the impacts on other systems and
users
• what the long-term costs and plans are to
support and maintain what's delivered
• what's most cost-effective overall
Tactical
management. It's product thinking for IT. approach
It's about moving away from a siloed approach to
a more holistic approach that brings more value
to the business (and, in turn, makes the role even Value to business
more important).
If you've used a business case to justify the delivery of an internal product, then measuring how you're doing
over time against the business case forecast is one approach. But what metrics should you use?
The answer is the metrics that make the most sense for your product and that are most helpful to your business.
The metrics might fall into areas like user behavior (e.g., takeup), cost saving, efficiency savings, uptime,
compliance or security.
For the platforms that underpin the customer-facing products, can you make a link to creating more revenue or
having less cost? For example, scaling up transaction volumes so you can take on more customers or having
a more stable platform, so you lose fewer customers. Maybe the business cases that exist for the external
products based on the platform already contain costs for platform development – or if they don't, they should.
Often the argument is that if we do nothing, there is an increased risk of a bad thing happening. For example, if
we don't tackle technical debt, the whole platform may collapse with the next update! Or if we don't stop 'shadow
IT' (where departments are buying their own laptops), we can't implement effective security solutions and risk
the whole company being compromised. Painting a picture of what would happen if the platform collapsed or
there was a serious data breach can very quickly focus decision-maker's minds.
Reducing time to market for new releases, business agility, or the ability to support longer-term product plans
can also be very important but are tricky to measure.
Of course, success is not just down to what you're doing in product management – it's based on the performance
of a cross-functional business team, ranging from Development to Operations. Objective Key Results (OKRs)
may be a good tool to use to get everyone pulling in the same direction.
With a product approach, the IT, or technical team changes from an order-taker to a trusted advisor. It moves
from the short-term view of reacting to a business request to considering long-term strategic value.
The product approach promotes more holistic thinking. For example: how each request supports long-term
business goals; how we aggregate similar requirements more efficiently; how to deal with the risk and cost of a
critical 3rd-party supplier letting us down; how we best align our infrastructure and support needs; what is the
long-term roadmap for this internal product to support our strategy?
It's about having a more balanced view of internal products. A view that considers the technical issues, our
customer and commercial constraints, and operational issues. The balanced view helps us to make objective
strategic decisions – that are best for the business.
As a trusted advisor, you can ensure difficult priority decisions are made – changing discussions from we want
this, this, AND this to we must choose between this OR this OR this.
In some organizations, all IT or Development does is build or install something, and then another team, like
Operations, must support it (and fix any problems). Often nobody has considered the need for long-term
management of the solution. Everyone has assumed once it's delivered, it's finished. Bugs and enhancements
are an afterthought for which no one has planned.
Internal product managers consider the full lifecycle of a product from development and deployment to in-life.
They also consider what will happen when a product needs to be withdrawn, and internal customers migrated to
something else. Unlike those product managers selling to external customers, internal product managers don't
have the option of telling the customers to 'sort it out themselves!'
So, genuinely owning the product and in-life management through the full product life cycle results in higher
quality, thought-out solutions for the business.
The product approach is more efficient. Here, you move from frequent code customization (a project approach)
to using or creating standard products that are configured for different users.
Making strategic build/buy/partner decisions (on what's best for the product and the business) is also critical.
Here product managers consider the options of building to add long-term value to the company, buying
commercial off-the-shelf software (COTS), which is readily available and more cost-effective, or partnering
where appropriate.
Another key commercial area is driving a better deal with suppliers by aggregating demand from multiple
business areas. Internal product managers have a view across the entire business and are well-placed to
manage this.
If a company has internal products - it's already doing some product management!
One of the first things to realize is that you don't need to have the title Product Manager to do product
management.
In many organizations, product management doesn't exist as a function, but plenty of people are doing the work
to manage products. A start-up may only have one product and no product managers. The senior management
team does most of the product management activities, e.g., working out the sales proposition, setting pricing,
and deciding what to build next. In other companies, there are Service Managers who pick up some of the
activities Product Managers typically do.
So, if a company has internal platforms/products, software services, or 3rd-party products – someone must be
planning what to do, building or buying them, deploying, operating, and supporting them. But, they may not
think of themselves as doing product management.
To relieve the pressure, recognize that saying 'Yes' to them means saying 'No' to someone else. Introduce
transparency into your prioritization process – everything goes through the same process, which helps you
make objective decisions. And work on communicating your plans, so you're not springing surprises on
senior stakeholders (they don’t like that).
Depending on the type of internal product, some activities will be more important than others, and some will
only be relevant in certain situations.
We've created a version of our Product Activities Framework for internal products, as shown below.
Insight
Technology research: Researching and gathering For example, understanding the landscape for
information, expert opinion, and insights. Tracking market 3rd-party solutions in a particular area.
drivers and trends such as technology developments.
Product performance: Reviewing data and reports on For example, monitoring platform performance,
performance, including analytics, to understand product tracking KPIs linked back to a business case and
usage. monitoring adoption rates.
Analysis
Internal segmentation: Identifying internal customer groups For example, segmenting within the business by
that need the same solution. Understanding the size and specific needs and understanding the numbers of
urgency of the requirements of these groups of users or potential users (e.g., providing different laptops to
internal customers. different user groups)
Propositions: Creating and capturing new ideas. Analyzing For example, creating different propositions for
and building propositions for the target internal segments. internal groups based on the same technology.
Direction
Product strategy: Developing internal product strategy and For example, selecting a single solution for use
plans. Updating management and the wider business. across the whole business.
Vision & Evangelizing: Creating a compelling internal product For example, telling the story of the importance of a
vision. Selling the vision to internal audiences, including key platform to the business. Explaining to users the
stakeholders and users. value of a proposed internal solution.
Roadmaps: Deciding on the future direction and priorities for For example, regular alignment meetings of the
the internal product. Publishing and maintaining roadmaps for platform roadmap with the product managers (of the
users, management, and other stakeholders. external products) that are using it.
Inbound Activities
- helping the business to deliver the product
Product discovery: Gaining a deep understanding of what’s For example, structured approaches like prototyping
valuable to users by exploring a known problem space to define and test ideas with internal users.
and validating candidate product concepts.
Requirements: Gathering, analyzing, prioritizing, and For example, platform requirements like performance
documenting internal product requirements. Defining users or scalability. Providing context and discussing
and use scenarios. trade-offs with developers and internal customers.
Operations: Ensuring the internal product performs at the For example, monitoring performance, Service Level
required levels Agreements (SLAs)
You can use this tool to check who owns which activity or work out what you need to spend more time on as
an internal product management organization.
Summary
We see a growing trend to adopt 'product thinking' for the management of internal products because of the
huge benefits it brings to a business. It's about focusing on building something once and having it used many
times, rather than creating lots of customized (and often flaky) solutions – that are costly to support and maintain.
It's about being proactive and providing leadership rather than constantly fighting fires. It's about having a
balanced and long-term overview of internal products – understanding the technical and operational issues
and the commercial constraints. This helps you make holistic, strategic, objective decisions on what's best for
the business. Finally, it's about understanding the internal customers and business well – to ensure that your
internal products deliver the right business outcomes.
Ultimately, your customer-facing products generate revenue, but your internal products will throttle your
business agility and reduce profitability if you don't have a product focus.