Business outcomes
Internal products must still provide business value. I focus on improving engineering workflows in ways that contribute to the organization’s goals - platform work is the foundation of the business.
Product
"Product management is about creating a product customers love, yet also works for our business" - Marty Cagan
🧳 My product journey #
- Networking
- Communication and Collaboration tools
- Engineering tools
These areas aren't traditional user or customer facing product areas, they're internal or platform areas. This is where I've spent my five years in product management. It's a challenging but exciting area, it's the foundations, it's a force multiplier, but it's also invisible.
📢 Public sector #
I've spent the duration of my product management career in the public sector. The public sector is non-profit, there are no competitors but there are real risks and challenges, especially around what's viable, often with an emphasis on fraud and error. Every penny spent is taxpayers money, it must be spent responsibly and we have to see a return on that investment.
Public sector products improve the lives of citizens - access to essential benefits, making it easy to file a tax return, getting a drivers license or passport - this is value.
📦 My product philosophy #
Internal product management is one of the most impactful but underappreciated parts any organisation. Internal platform product managers don't just collaborate with engineers to build tools, they reduce friction and cognitive load, enhance engineering productivity, and enable the rest of the organisation to solve end user problems.
My philosophy centres in treating product teams as users. That means understanding engineering workflows, pain points, needs and desires and prioritising to achieve strategic outcomes and keeping the lights on over shiny features.
I empower our team and engineers to care not just about how a tool is built but why it's built. Everyone on a product team is a product person, engineers aren't just programmers, they are problem solvers.
I think good internal product thinking is strategic and user centred - empowering the organisation to achieve outcomes.
👷 Building for builders #
Being an internal product manager is tough, unlike customers who don't know what is possible, our users are primarily engineers and have ideas and opinions about what is possible. The goal remains the same though, how can we improve the lives of our users?
Our products are technical, and often 3rd party tools, so having deep knowledge of the product is challenging without engineering experience. I spend more time growing my technical skills but this is an investment that will benefit me long term allowing better collaboration and conversations with users and stakeholders. I don't think you can be an internal product manager if you don't have the ambition and agency to develop yourself technically.
To help me and our team build for builders, I always strive to follow my product philosophy and the pillars / principles set out below.
🏛️ Product pillars #
This bikablo style drawing visualises my opinionated internal product pillars. These principles shape how I approach internal product management. You can discover each one below - I’ll be sharing more in future blog posts and / or case studies.
User needs
Our users are engineers - not end customers - but they're just as important. Understanding their workflows, pain points, needs and desires is key to building tools that solve hard problems.
Discovery
Discovery isn’t user research - it’s collaborating with engineers, exploring tech constraints, and de-risking our ideas. Discovery is continuous, not a standalone phase.
Validate ideas
Linked to discovery, before building anything, we validate our ideas: Does it solve a real problem? Would someone use it? Can someone use it? Can we build it? Does it work for the business?
Build
Working closely with engineers we spec up and 'productionise' our validated idea ensuring it's built and delivered to the required quality standard.
Launch
Internal launches need clear communication meeting engineers where they are. We strive for comphrensive documentation, demo's / walkthroughs, and act quickly on feedback to ensure successful launches.
Evaluate (bonus)
We need to measure the success of the tool/product/feature. Has it solved the problem?
Iterate (bonus)
If we haven't solved the problem we need to iterate. That said, no product is ever 'done', we continuously iterate to solve new problems. We make the space to do this.
Love
The best products are loved, but this is challenging for internal users who see something as a necessary tool to do their job. However, we strive to delight and show that we care about our engineers.
📖 Product stories #
🔜 Real examples of how I apply my product pillars to solve problems, build tools, and achieve outcomes.
