Internal products need project management
When you see the benefits of it, you’ll forget the blame
Hello, I’m Tiago Ferreira, Sr. Product Manager in Brazil with +6 years of experience crafting products. With The Next Movement, I want to share part of my product management experience with the whole world, but also talk about career more broadly, technology, good books, and - why not? - philosophy, music, culture, gossip, just like an open diary. If you enjoy reading my article, subscribe and share it with your friends 🤓
Internal products usually demand a lot of alignment and expectations. And, in most times, their interfaces suck, because the leaders don’t want to allocate the same amount of resources as customer-faced products.
Kari McMahon get it right on her post for UX Collective:
“The engineer on the team will often wear many hats - one day they are sketching designs, the next coding and then releasing the software. These teams don’t deliberately want to create bad applications. They are often charged with working on a legacy system or designing an application which will interact with a legacy system.”
I could get myself lucky when I worked on an internal product with more dedicated resources than any other team inside the tribe.
Probably because the product was responsible for configuring prices, benefits, and registering partners in the B2B sector for a giant retail company in Brazil.
However, speaking with different colleagues who also led internal products, I saw a pattern that most of Product Managers often don’t like to be associated with: project management.
That’s easy to illustrate.
Project management could facilitate communication
An internal product usually needs to solve back-office problems. For a product responsible for pricing, for example, an error could cause a lot of damage to different areas. So, you need to involve more stakeholders, share decision-making, align a resolution, and deploy only after eliminating as many risks as possible.
It is complicated to work with MVP in internal products because the stakeholders tend to prefer security over velocity. And that’s not a bad thing at all. Your team probably doesn’t want to feel guilty after pressing pull request considering an important change that could affect the core of the company.
The good thing about project management is to communicate a sense of good prediction. Every company I worked at demands deadlines, and it’s more comfortable to give an extended-release date than a short-term date that could affect the core of the product.
If you clearly communicate the plan for release, you probably will not have problems with your stakeholders. Even if this tactic doesn’t work, talk about the risks in a collective sense: we don’t want to deploy a feature that could affect the final price for the user. In business terms, that sounds logical.
Also, project management mindset allows you to involve finance in your forecast. I know waterfall is not appreciated when you work with software development, but it’s important to address the cost of opportunity in internal products. Wherever possible, ask yourself this question:
Is the time needed to develop and test well worth it compared to the risk of launching a feature that could affect the core component of the business?
Just don’t forget to communicate well all the process until the launch date. User story mapping could help you because, in most times, some functionalities are intricated with others, and the stakeholders want to visualize that.
Of course project management doesn’t apply to all internal product cases. It’s important to consider agile, user experience, discovery, and other product artifacts with internal users.
But, more often than you’d like, you’ll need to put on the project management hat. When you see the benefits of it, you’ll forget all the blame.