Internal products often begin with a PO hearing, “here are the requirements,” and end with a user hearing, “you’re required to use this.”
Of course, this is disempowering for internal product owners and for users. It’s also a recipe for a product that misses the mark.
When there’s no need to persuade a user to buy a product, to engage with it, to not switch to a competitor, the focus goes to functional jobs. What’s the tactical thing this person needs to accomplish? Create a new lead. Add details to an opportunity. Generate a report of active deals.
Do they love using the tool? Who cares? It’s their job.
These tools generally do the tactical things they’re supposed to do (at least the tactical things someone remembers to put in the requirements). The salesperson can indeed add details to an opportunity. The functional tests pass.
So what’s the problem?
Work Is More Than Tasks
Most people’s biggest source of identity, meaning, and motivation is their work. We spend more time working than any other single thing. We experience (or fail to experience) autonomy, mastery, and purpose through our work more than any other area.
If I feel like my work matters, if I feel like I’m good at it and getting even better, if I feel like I have control of how it do it…then I’m going to be more motivated and engaged. I’m going to do my work better. I’m going to have more energy to give to it. (And, by the way, I’m likely to have more energy for the other things in my life, too, because work doesn’t suck the life out of me.)
Good Tools Increase the Right Things
Good tools increase autonomy, mastery, and purpose. Bad tools decrease them.
Good news: Not only is it possible to create internal tools that increase engagement while also meeting all the functional needs, you’re actually more likely to get a functional product if you pay attention to what really matters to users.
I was probably being generous when I said internal products “generally do the things they’re supposed to do.” More accurately, they do something like what somebody wrote down in a document or Jira ticket. Perhaps not what the user really needs. Maybe not particularly usable. Probably missing some not-so-rare edge cases.
Treat Internal Products Like Real Products
Instead of just collecting feature requests or gathering requirements, internal products are worth treating like real products.
Do actual customer research. Observe and interview users. Develop an understanding of not just what tasks they need to do but what would make them feel more competent and higher-impact as they do those tasks.
Then, test small increments with real users, get feedback, and act on it.
Better internal products means happier users which means more effective employees, more satisfied customers, and better business results. Internal products may not have a customer paying for them directly, but they’re definitely connected to business outcomes.
Learn How to Build Products That Work
Our redesigned Advanced Certified Scrum Product Owner program launches next month, and it’s crafted especially for internal POs. Over the course of six weeks of live learning and real practice on your actual product, you’ll develop the skills and tools to craft internal products that deliver business results. Real product development, not requirements administration.
Learn more and register today!
Last updated