The Internal Product Breakdown
“What do you do for work?” is probably the most loaded question I can get in a social situation. While the practice of product management is not new, INTERNAL product management is a relatively unheard of discipline.
Typically when I attempt to describe “what I do”, people confuse my job with a PROJECT manager. It’s pretty frustrating to have to correct them when they use that term. But I think all product managers encounter this to some degree. :)
So let’s get to answering the burning question, what do I do?
I’m not responsible for a product that generates revenue. Rather, I am responsible for a product that is used to streamline business processes.
Defining jobs to be done in this area of product management can be achieved by watching someone do their day to day job.
I know that sounds pretty meta. And it is. My job is to help folks do their jobs more effectively at my company. My customers are staff.
While they don’t buy the product that I’m developing, they use it everyday!
Some visuals will probably help.
The screen shot above shows the home page of the UI. This is essentially a landing space that customizes the user experience based on a user’s in progress and completed work. It helps the user to prioritize their next steps.
Based on user discovery and insights, my engineers, designer and I determined that filters would offer up flexibility and clarity around ownership of work.
You will also see in the component on the bottom some red indicators. Because my company deals with content libraries, that content often needs to be evaluated for out of date elements. Those signals are powered by a data model behind the scenes. Working with data scientists is fun!
Before my team existed, our curriculum designers were using spreadsheets to deliver their instructional intent. Have you heard the phrase, “Spreadsheets are not databases.”? It’s true. While spreadsheets offer up a lot of benefits, data visibility is not one of them.
This data drives the planning motions for vendors we work with who create the content. It also drives Marketing and Sales decisions. So having the data standardized for downstream partners was essential. It needed to be in a database and formatted so that other teams could replicate and interpret the data.
Out of that need, my product experience team was rallied and the UI I have been describing was conceived.
To map this all out, we needed to create a new Entity Relationship Diagram. We paired this with the mental model of the users and the practice of backwards design. That is how we landed on the tab design you see above. We needed to give the users a method for organizing their data that was flexible, but consistent.
Although my customers are staff and I’m not selling a commercial product, the tenants of my job are the same. Listen ferociously to your customer and design based on quantitative and qualitative research findings.
