Product Transformations and Internal Products
Transformation at File Perfect Wikimedia Commons

Product Transformations and Internal Products

Do you work at a company switching from a project to a product approach (ie undergoing a product transformation)?

If so, and that company is in an industry that doesn’t actually sell software products, you most likely work on internal products, or you’re an IT Product Manager.

You may also not really care what it’s called but would like some advice on how to do it in your context, especially the messy bit about making the change from working with a project paradigm to working with a product mindset.

I’ve had the opportunity(?) to work with several companies going through a transformation of one sort or another (agile, digital, and product). The path is never a smooth one, mainly because there is considerable change involved.

In this issue of InsideProduct, I wanted to share some resources for folks currently going through a product transformation to highlight the challenges you may face with a product transformation and some ways you can address them.

Challenges and Suggestions for Addressing Them

Common Transformation Pitfalls

Let’s start with Marty Cagan, who, in ?this ProductTank Oslo talk?, is not shy about pointing out what companies commonly get wrong about their product transformations. Marty tends to focus on tech companies, but some points he makes are particularly relevant for tech-enabled companies such as financial services, healthcare, manufacturing, or retail.

Those pitfalls include project-based funding, technology as a cost center, and the overwhelming desire for processes and tools. Based on some recent experiences, this last point is particularly impactful in organizations that have a PMO (project management office or portfolio management office).

The folks from the PMO see the product transformation as threatening their existence at the company, so they try to water down the move to a product approach, often resulting in still following project practices but calling them different names. This is not helpful.

Marty spends most of his time identifying pitfalls, so you’ll have to look at some additional resources to get some suggestions for addressing them.

Why Transformations Fail and What You Can Do About It

?This article from the Forbes Human Resources Council? takes a look at the human side of product transformations and offers up three things you can do to smooth the massive change that organizations face. The key points:

  1. Don’t think about “transformation” as something that’s fixed. Think about “transforming,” where you identify a direction but do not attempt to control the process nor detail the outcome fully.
  2. Don’t focus so much on changing formal structures and processes that you lose sight of the values and behaviors you impact while transforming.
  3. Focus on addressing things that people identify as current obstacles. It’s much more energizing for teams to focus on removing definitive obstacles rather than longing for a future scenario that often is not tangible. Also, organizational change needs to start with the behavior and mindset of the top leaders.

Three Tips for product managers at companies learning how to do product

For some additional practical advice, Marta Rolak, Product Director at Springer Nature, shares ?three tips for people undergoing product transformation within their own organization?.

Communication is Key

Invest significantly more effort into communication and stakeholder management than you would at a company with a strong product culture.

Accept there will be many feature requests and deal with it

Stakeholders will come to you with feature requests all the time. Instead of getting frustrated, have an open dialogue to understand what they are after. This is your chance to show you’re interested in finding a solution to a problem that’s clearly important to them, and over time, to build a trust-based relationship.

Find allies. Don’t walk it alone

You might find many people in your organization who are naturally more interested in technology. Maybe it’s someone in customer service or a seemingly reluctant stakeholder. This is a wonderful common ground to build on, so invest in creating personal relationships; having technology advocates among colleagues who sit outside of the technology organization is invaluable.

Helpful Case Studies

If you read through the above tips and said, “that’s great in theory, but what are people really doing?" Here's a couple of examples.

Kimberly-Clark is learning to act like a tech products company

Venture Beat described ?how Kimberly-Clark, a consumer products company, is learning to act more like a tech company?. A key point in the article that you may find useful:

The idea is to avoid focusing on projects, or limited time commitments to develop and deliver applications that will be declared “done” at the end of the process.
By thinking instead in terms of products, technology teams can organize themselves more like software companies who will build a minimum viable product they can bring to market, promote, and then continually improve in subsequent iterations.

Project to Product Transformation Case Study: Global Media Service Provider

IT Revolution shared the story of ?a multinational corporation providing business support systems via a SaaS model? (SaaS-based multi-tenant back end). Their most important product is customer care systems to large service companies in the healthcare and telecommunications markets. One key aspect of this story is the following:

A more difficult transition was moving away from a more traditional PMO to a portfolio leadership group. In fact, this only happened after the CIO was replaced. In the new setting, the project management capability is embedded in the product group. In addition to project management, the group also looks at investment and the communication plan. Moving away from the old mental model required a lot of “soap boxing” to sell the new journey.
As our interviewee stated, “We realized that this wasn’t just a change of nomenclature. It’s also behaviors and ownership. When you switch to a product focus, you are paying for a product backlog in perpetuity until you sunset the product. That’s a different mental model than a project that you start, drive to completion, have a budget, etc.”
The company now has only three or four project managers who oversee massive epics that cross many teams and usually involve customers. For example, a recent improvement needed intensive coordination with customers to upgrade 30,000 external connections. Although the work on the back end was reasonable, it took a long time. Project managers worked on this project for over eighteen months.

Project to Product Transformation at a Fortune 100 Retail Enterprise

IT Revolution shares the story of a Fortune 100 retail enterprise demonstrating sustained progression through the three stages of enterprise product transformation.

Their journey began with grassroots experimentation in a few technology teams within the digital and API platform organizations. As initial success was seen in this experimentation, they also spanned their new practices across a few mainframe and monolithic applications.

A key aspect of this story was the creation of a Dojo to demonstrate and accelerate the full-stack product model. Coaches supported immersive learning experiences within the Dojo and quickly educated workers on the new product team roles.

Do you Like What You're Reading?

Subscribe to InsideProduct to get the newsletter before everyone else when it comes out every other week.

要查看或添加评论,请登录

社区洞察

其他会员也浏览了