Product management

"Product management is about creating a product customers love, yet also works for our business" - Marty Cagan

# 🧳 My product journey

1. Networking
2. Communication and Collaboration tools
3. 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.

# 👷 Internal product management

Being an internal product manager is tough, unlike customers who don't know what is possible, our users have an idea about what is possible. 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.

# 📢 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 management philosophy

This bikablo style drawing used to be my sites homepage image, I'm terrible at drawing but I was proud of it so I'm using it here to visualise opinionated key areas of product.

Below is a brief overview into these and some bonus areas of product. Future blog posts will cover any deep dives.

# 🎯 Business outcomes

Starting with business outcomes because in a for-profit organisation if your product doesn't sell you won't be in business. You might have a product that solves a user problem, but can it be monetised and marketed?

Product strategy provides strategic context to product teams to allow them to solve business problems, with ideas that solve user problems. Product strategy is hard!

In the public sector, we're not seeking to grow revenue or make a profit, we're delivering policy and legislation.

# 👤 User needs

Closely related and arguably first, does the product solve a problem for users that improves their life? Does it meet user opportunities such as, needs, pain points or desires.

# 🔭 Discovery

Product discovery is all about discovering the problem and solution space, exploring the key product risks and validating our product backlog. I tend to simplify the user or business problem we're looking to solve by using one of these short formats:

[User persona] needs a way to [do something] because [driver]

or

How might we?

The short formats keep the problem clear by avoiding long paragraphs trying to describe the problem. The more you write the more you can confuse the problem space.

# 💡 Ideas

Ideas for solving the problem form the bulk of solution discovery. This is where we explore the product risks of:

• Desirability. Does a user want or need this?
• Usability. Can a user use this?
• Feasibility. Can we build it?
• Viability. Is it viable to build?

Shout out to Value. Value is often used interchangeably with desirability. We can view value as, user experience, expenditure, efficiency and effectiveness.

# ✅ Validate

Testing ideas using prototypes with users. Some folk call this experimentation, some might say assumption testing or hypothesis testing but it's all much of the same thing. Have we de-risked the ideas so we can decide if we should build any of them.

# 🔧 Build

We've validated an idea, now we can spec it up and build it, in this sense it's "productionising". The idea to solve our problem could be a new product, a new feature or an enhancement to an existing product / feature.

# 🚚 Delivery

This often means delivery management and agile but it's often talked about in the sense of how we build. This includes factoring in non-functional requirements or constraints such as scaling, performance, resilience, monitoring - all things that contribute to a products quality. This also includes modern DevOps practices such as Continuous Integration and Continuous Delivery / Deployment (CI/CD). In CI/CD we continuously integrate and test code changes before delivering into production manually or automatically on a regular basis.

# 🚀 Launch

We've built the product now it's time to launch and go live. We need to drive adoption and get users to become good at using the product so they can have their value or ah ha moment. Without this, initial excitement could become churn.

# 📏 Evaluate

Has the product been effective in solving the problem? Discovery doesn't guarantee success. We need to evaluate and measure our success, objectives and key results is one common framework. If we haven't succeeded we need to iterate. If the product is successful we don't stand still, we iterate.

# ⚙️ Iterate

We need to continuously improve our live product. We discover new problems and opportunities to add more value and get more users using our product. Iterating is the start of a new cycle, we go back to our outcomes, user needs and discover new ideas.

# ❤️ Love

This is the end goal. We want to improve our users lives to the extent that they love the product. This is sometimes called loveable and some companies use it in their product maturity framework.

Many public sector services won't achieve lovable status due to their nature, it's unlikely you're going to love filing a tax return, but doing this on a digital service is a significant improvement to paper forms - this is value encapsulated.

💭 What do you think? Let me know!