Archive for the ‘Product Management’ Category

These are some product principles that help me make decisions:

  1. We listen to our customers daily, have empathy for them and act on key insights
  2. We understand the market and our customers needs
  3. We work with the rest of the business together to solve the highest priority problems and opportunities in a lean way
  4. We build quality products and features which customers love; recognising that delivering customer satisfaction will grow the business
  5. We have clear product ownership where we are empowered to deliver excellence aligned to the business goals
  6. We trust by giving autonomy at every level across the product delivery lifecycle
  7. We spend time celebrating successes and continuously learn
  8. We acknowledge that there is no bad question or wrong answer and have an inclusive mindset
  9. We see mistakes and failures as a learning experience
  10. We have a strong product organisation, which enables us to achieve our ambitions

Product Owner is a job role that came out of Agile and Scrum, and although many organisations use it as a job title that is interchangeable with Product Manager, it’s not correct. In Scrum the Product Owner is defined as the person who is responsible for grooming the backlog, in Agile it was defined as the representative of the business, and neither entirely describe the full breadth of a Product Manager’s responsibilities.

Product Owner is a role you play in an Agile team, whereas a Product Manager is the job title of someone responsible for a product and its outcome on the customer and the business.

Now a lot of Product Owners out there are great Product Managers, and they should just change their title. But a fair number of Product Owners have simply completed a certified Scrum product owner course and now think they’re equivalent to a Product Manager, which sets them up to fail as they never consider the broader role. So if you’re tasking a Product Owner with the broader product management responsibilities, make sure you provide the training they need to master the full breadth of the role (and then change their title).

Enjoyable short read, where Roman Pichler describes the key product leadership challenges, along with ways to use your heart and mind to work effectively with the dev team and stakeholders to create value together.

Roman talks about mindfulness and the leadership-related gains for product people it can have such as greater serenity, increased empathy and better decision-making.

To focus on the important, but less urgent work you need to “be willing to set boundaries, say no, and let go: You can’t do everything without either neglecting your core responsibilities or sacrificing your health, neither of which is desirable.”

But also success doesn’t happen by magic, as Roman explains that “in addition to embracing a can-do attitude, achievement requires effort and discipline. The better we want to become at something, the more effort we have to invest.”

Leaders need to “be a role model and exhibit the behaviour you want to see in others. Listen empathically, speak truthfully and kindly, and make an effort to be open-minded.”

A must read for both new and experienced product people.

This colossal 786 page desk reference provides a fantastic perspective for professionalising Product Management, inspired by Steven Haines vision for this profession.

Throughout the book it focused on a Cross-Functional Product Team, which most people would immediately think would be just a PO/PM and dev team, but instead it was refreshing to see product in the centre of the whole organisation and that product team including someone from marketing/sales, customer service, operations, development, legal…..also in my experience when a product manager brings this team together is where the magic happens.

Steven explains regardless of development methodology, it’s important to remember that the product manager is in charge of the product’s business, not just the product’s functionality, design or features.

“No one will bestow Product Management leadership on you. It is yours to own, to internalize, and to practice”

“Product Managers will earn greater levels of credibility across the organization when they understand and act on proven facts and relevant data”

This book will remain on my desk and I’d recommend it to any ambitious product manager.

A very timely book by Marc Abraham with Covid adding more tension to everyone’s lives.

Whilst it does take experience and confidence before you can lean into tension effectively, Marc explains that embracing tension is also not easy, but it is absolutely worth it!

Marc explains the benefits of ‘accepting radically’ with tips on how to allow your mind to accept things for what they are (and aren’t), so that you can focus your mind and energy on things you can change which result in more productive outcomes.

“Tensions are inherent to products and that we as product people should find ways to embrace that”

“Pressure is an integral part of life, work, being. We might as well accept this tension, starting with a full awareness of how we perceive tension and how others around us view our perceptions and behaviours”

“When curiosity is combined with passion in the exploration of a subject, an individual may be able to acquire an amount of knowledge comparable to that of a person who is exceptionally intelligent”

“Keeping on top of your product means continuous learning and improvement, with a relentless focus bettering your ways of working”

What a brilliant way of explaining the benefits of DevOps and Agile, through this novel by Gene KimKevin Behr and George. Spafford.

This book takes you on a journey where it articulates beautifully the problems which a lot of businesses have pre digital transformation – the politics, the waste, the chaos, the inefficiency of getting ideas to customers, lack of innovation alongside the benefits of adopting a DevOps culture and practices to solve these problems.

It amazed me how accurate the book is and brought back fond memories of the DevOps journey we went on in my previous job, the value it created and a challenging time when I had to juggle similar competing priorities all at once like Bill and Chris did with big projects relating to urgent security, compliance, stability/performance, tech debt and live issues alongside everything else all at once.

Coincidentally half way through reading we were releasing one of the biggest software releases I’ve been involved in, so it made the reading even more exciting and inspiring.

“Every industry and company not bringing software to the core of their business will be disrupted”

You can’t get a more comprehensive book on product leadership than this by Richard BanfieldMartin Eriksson & Nate Walkingshaw, where they explain in detail what it means to be a product leader, how they launch great products and build successful teams.

“For many product leaders, work life is a constant tension between delivering value to one group and telling another they can’t have what they want. Shipping product, and its associated value, is the reason these product leaders get up and go to work”

“It is not about individual success, it’s about getting the best out of others”

“What is common in high-performing teams is that they are cross-functional, collocated and autonomous”

How to identify product leaders:

🔸️ Plays well with others
🔸️ Seeks challenge
🔸️ Gets their hands dirty
🔸️ Always acts and thinks “team first”
🔸️ Is comfortable wearing lots of hats
🔸️ Displays curiosity
🔸️ Communicates well
🔸️ Possesses selling skills
🔸️ Has exceptional time management skills
🔸️ Is a visionary
🔸️ Shows equanimity/grace under fire

This has to be the best book I’ve read on product management. I loved the way Marc Abraham has put his heart and experience into every chapter making it extremely authentic and realistic when talking about the different techniques and the challenging scenarios that a product manager often faces.

The book has a good structure to each subject which includes the goal, related tools and techniques to consider, in-depth look, key takeaways and how to apply these takeaways.

Marc explains “Product Janitors..

..because product management can be such a broadly defined role, there is a risk that product managers end up doing a bit of everything-mopping up the things that other team members do not want to do..
..as a result, these product managers are unable to act effectively, by which I mean they fail to identify and manage products that are valuable, usable and feasible”

“When you spend more time talking to ‘internal stakeholders’ than your customers, you’ve lost the ship”

Another nugget from this short read “if I had an hour to solve a problem I’d spend 55 minutes thinking about the problem and 5 minutes thinking about the solutions”- Albert Einstein

A short read by Kevin Brennan which provides a high-level guide on 52 approaches covering the full breadth of Product Management.

Because of the way it’s laid out, it makes it easy to refer back to when you’re next putting together a business case, product strategy, product manager’s job description etc, so it makes a good desk reference.

It was nice to read Steven Haines view on product management. Another good book for anyone wanting a solid overview of the product manager role…

“Many people confuse product management with product development, and some confuse product management with project management…

..The system of product management touches and influences all the organic supporting structures-all the business functions. Think of the human body; product management is in the circulatory system, the neural network, and, of course, the command and control center (the brain).”

Amazon’s CEO Jeff Bezos says “We see our customers as invited guests to a party, and we are the hosts. It’s our job every day to make every important aspect of the customer experience a little bit better”

“Success is not final, failure is not fatal: it is the courage to continue that counts” – Winston Churchill

And the final nugget from the book “measure twice, cut once”.

Want to know more about the product manager role?

New to product management?

Stuck spending most of your time on tactical work and need a recap on the fundamentals of being a product manager?….

…then I’d recommend this book by Josh Anon where he’s written a really good comprehensive guide to becoming a great product manager.

The way this book uncovers the key capabilities that drive improvements in software delivery performance is brilliant.

It was interesting to read the science behind the research findings and the rigorous research methods used which was predominantly done by surveys, which I’m a big fan of.

I’d definitely recommend this book by Nicole ForsgrenJez Humble and Gene Kim

Whilst I have minimal B2B product experience, this book by Geoffrey Moore gave good insight into the complexities and challenges of scaling high-tech products, as well as practical advice on how to avoid the various pitfalls when attempting.

Although the Crossing the Chasm model is B2B, I couldn’t help notice how many similarities there were to B2C when it comes to scaling a product to mainstream customers with a ‘whole product’ offering and targeting customer segments.

A fascinating read by Thomas M. Siebel where he writes about how enterprise digital transformation powered by cloud computing, big data, AI and IoT (Internet of Things) has caused mass extinction and mass diversification in the business world…..

PwC’s 2017 study projects an increase of $15.7 trillion in global GDP by 2030 due to AI.

Analysts expect IoT will contribute up to $11.1 trillion in annual global economic value by 2025.

Industry analysts estimate that the AI software market will exceed $250 billion by 2025.

A nuclear electromagnetic pulse (EMP) attack would disable the vulnerable US power grid for years with only 1 in 10 Americans surviving after one year.

My experience with digital transformation is to always start from problems to solve (use cases) / business value rather than diving into ‘data lakes’ which could swallow up years of resource with minimal business value.

Great read by Marty Cagan which covers the entire Product Management area.

Whilst a significant amount of the book is focused on the importance of solving customer problems – outcomes over outputs, which is the theme of a lot of product books around, there are 67 chapters covering:

> The different growth stages of tech companies, lessons and some really good success stories from Product Managers of Google, Adobe, BBC, Microsoft, Netflix and Apple
> The challenges and the reality of being a Product Manager
> The different roles of the Product/Agile team, supporting roles and additional leadership roles needed as you scale
> Tons of advice about product vision strategy and KPIs
> Huge amounts of discovery and transformation techniques
> Stakeholder management

And it also accurately describes the top reasons for loss of innovation and loss of velocity.

This was a good read by Terry Schmidt, with some fantastic practical tools such as the LogFrame used for strategic product planning, which also generates a hypothesis.

A good alternative to the VMOST framework.

Agile

Whilst Agile frameworks such as Scrum and Kanban are a great way of taking steps towards becoming more Agile, it’s important to remember amongst their own principles and guidelines, that the ultimate objective is to deliver customer value/the product vision in an efficient and competitive way.

To help avoid losing sight of this objective and falling into the trap of obsessing about the intricate details of the frameworks too much, it’s important that gap analysis is done frequently on the actual Agile manifesto and principles themselves to see how you can shape the Agile framework to achieve agility and the real benefits of being Agile.
The 4 Agile Values/Manifesto

  1. Individuals and interactions over processes and tools
  2. Working software over comprehensive documentation
  3. Customer collaboration over contract negotiation
  4. Responding to change over following a plan

The 12 Agile Principles

  1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
  3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  4. Business people and developers must work together daily throughout the project.
  5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  7. Working software is the primary measure of progress.
  8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  9. Continuous attention to technical excellence and good design enhances agility.
  10. Simplicity–the art of maximizing the amount of work not done–is essential.
  11. The best architectures, requirements, and designs emerge from self-organizing teams.
  12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

How Spotify have adopted Agile

Analytics

The short answer is yes – the product/team will definitely benefit by having web/app analytics tracking as part of the definition of done (DoD).

The only time that a separate analytics tracking story should be written and played is typically in the scenario of:

  1. There’s no existing analytics tracking, so there’s tracking debt to deal with including the initial API integration
  2. A migration from one analytics provider to another

The reason why it’s super important to ensure that analytics/tracking is baked into the actual feature acceptance criteria/DoD, is so then:

  1. It doesn’t get forgotten
  2. It forces analytics tracking to be included in MVP/each product iteration as default
  3. It drives home that having tracking attached to a feature before it goes live is just as important as QAing, load testing, regression testing or code reviews

Unless you can measure the impact of a feature, it’s hard to celebrate success, prove the hypothesis/whether it delivered the expected outcome or know whether it delivered any business value – the purpose of product development isn’t to deliver stories or points, it’s to deliver outcomes.

Having a data-driven strategy isn’t the future, it’s now and the advertising industry adopted this analytics tracking philosophy over two decades ago, so including analytics tracking within the DoD will only help set the product/team in the right direction.

Velocity

Velocity = Projected amount of story points which a team can burn over a set period

A development team’s velocity using Scrum or Kanban can be worked out by totalling up the amount of points which has been burned across 3-5 sprints/set periods and then dividing it by the periods the totals were calculated over (taking an average across the periods).

It’s important to use an average across the last 3-5 periods, so then holiday seasons and a sprint where items have moved over to the following sprint doesn’t dramatically impact the numbers as much as it would if you only looked at the last period.

A team can use their velocity in many ways, for example:

  • Understanding how many points they can commit to during sprint planning/work out how many PBIs (Product Backlog Items) could be done across the next 2 weeks
  • To aid prioritisation (The ‘I’ in ROI)
  • Predicting when software can be delivered in the backlog, which can then be used to forecast future feature delivery
  • Understanding the impact on any resources eg. Scrum team member changes or adding extra teams to the product
  • Understanding the impact which dependencies are having which can be reviewed in the retro, great example being build pipelines
  • Providing a more accurate estimate than a t-shirt size
  • As a KPI for efficiency improvements

I tend to refer to points being ‘burned’ rather than ‘delivered’ because it’s quite easy to fall into the velocity/story point delivery trap of obsessing about points being delivered rather than obsessing about delivering outcomes (business value).

Devops

Development effort isn’t cheap, but extremely valuable no matter what industry you work in, so once a product iteration is ready to ship, automating the final steps including the software build, deployment, environment and release process will help continuously deliver customer value in an efficient way without unnecessary delays or bottlenecks.

DevOps is the combination of cultural philosophies, practices, and tools that increases an organisation’s ability to deliver applications and services at high velocity: evolving and improving products at a faster pace than organizations using traditional software development and infrastructure management processes. This speed enables organisations to better serve their customers and compete more effectively in the market.” – AWS

There’s often a significant amount of thought and effort which goes into getting an idea into development, so when the code (solution) is ready to kick off the build (ship) process, it’s important that this is as automated as possible to avoid unnecessary delays with customers getting hold of the feature within a timely fashion.

Due to the rise of the DevOps culture, it’s now possible to automate the whole build, deployment and release process. As well as customers getting features sooner as mentioned above, other benefits of adopting a DevOps culture includes:

  • Software Development division remaining competitive
  • Reduction in waste from having to wait for software to build, deploy, dealing with environment issues and working with the operation team to handle the release
  • Increasing the R in ROI (Return on Investment) as less waste results in delivering more value to customers
  • Improving team morale – dealing with environmental, build and release issues manually isn’t fun
  • Improving on sprint goal complete rates as it’s less likely stories will drag over to multiple sprints because of build / release issues
  • Decreasing lapsed time of development work
  • Improved security
  • Easier to track build to release timeframe
  • Automated
  • Scalable

Adopting a DevOps culture should ideally come from bottom up rather than top down – a Product Owner shouldn’t need to create stories, sell in the importance of it to dev teams or prioritise it, as optimising the software build and release process should be BAU (Business as Usual) and should always be constantly looked at and improved.

As development teams adopt a DevOps culture and they start migrating over to a fully automated process, the benefits will be obvious and lucrative.