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.
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.
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:
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.
If you read through the above tips and said, “that’s great in theory, but what are people
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:
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:
IT Revolution shares the story of a Fortune 100 retail enterprise that demonstrated sustained progression through the three stages of enterprise product transformation.
Their journey began with grassroots experimentation in a small number of 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.
Thanks again for reading InsideProduct.
If you have any comments or questions about the newsletter, or there’s anything you’d like me to cover, reply to this email.
Talk to you next week,
Kent J. McDonald
Founder | KBP.Media
Hand-picked resources for product owners, business analysts, and product managers working in tech-enabled organizations. Check out the resources I offer below and sign up for my newsletter!
I try not to overuse click bait titles, too much. For this particular topic, however, it was just too tempting. As I mentioned in a previous newsletter, there were several reasons I went to Agile2024 after a six year hiatus. One was to get a sense of the current state of agile. There’s been a bit of chatter about the decline in agile coaching opportunities as well as trends in agile transformations in general. I certainly caught some inklings about what’s going on, but I didn’t want to rush...
I’m back from Agile2024, and it was good to be back after a 6 year hiatus. I caught up with some old friends, made some new acquaintances, and had some great discussions along the way. Some of those discussions will influence future issues of InsideProduct, and others will go down as obnoxiously long running inside jokes. If you're wondering about the latter, ask me about retractable stairs or comic sans the next time you see me. While I’m not going to talk about those topics here, I did want...
For the last few weeks, I’ve explored what prioritization looks like in a variety of different scenarios. This week finished up that series with a look at how you can go about prioritizing a bunch of stakeholder requests. This is a common scenario when you’ve already built software for your company (ie internal product) and you’re trying to optimize or maintain it. A unique aspect for internal products is that most requests for changes come from other people inside your company who may, or...