The First 90 Days

Posted: Jan 1, 2021 in Book Reviews, Business
Tags:

Transitioning to a new role can cause anxiety and stress for weeks, but this book by Michael Watkins helps diagnose your situations, define the core challenges, and design plans to create momentum which results in a more successful and comfortable transition.

Hundreds of thousands of leaders have benefited from this approach, which independent research has shown reduces time to break-even by as much as 40%.

The book includes case studies of failed transitions and clearly explains how to avoid them by preparing yourself, setting your boundaries, listening, learning, collaborating, creating alliances, securing early wins and managing yourself.

“Effective leaders strike the right balance between doing (making things happen) and being (observing and reflecting)”…

…this nugget from the book is equally true even when you’re not transitioning to a new role.

I’d definitely recommend this book.

The Leadership Engine

Posted: Jan 1, 2021 in Uncategorized

Really glad I bought this book by Noel Tichy – the inspiring stories and explanations gave me plenty of opportunity to self-reflect about my leadership capabilities, which has explained a lot and given me confidence that I’m heading in the right direction.

Tichy explains how organisations that have a Leadership Engine win because they have leaders at every level who teach others to be leaders. Teaching and learning are at the heart of these organisations.

“A crucial element in this process is that winning leaders and winning companies use mistakes as coaching opportunities rather than causes for punishment. Treating mistakes as learning experiences, in fact, is one of the ways in which winning leaders encourage others to develop edge and take the risk of making tough decisions.”

I’d definitely recommend this book.

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.

Fantastic book by Stephen R. Covey

If you’re into self-improvement I couldn’t recommend this highly enough.

Four generations of time management:

1st generation – notes and checklists

2nd generation – calendars and appointment books

3rd generation – important idea of prioritisation, of clarifying values, and of comparing the relative worth of activities based on their relationship to those values

4th generation – recognises that “time management” is really a misnomer-the challenge is not to manage time, but to manage ourselves

5th generation – tbc

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.

Incredible book by Robert Cialdini which includes ~50 amazing experiments from psychologists around influence, as well as a great selection of experiences which Robert has been through himself.

I found the most fascinating chapter was around reciprocation, because it explains why those who naturally give/help others out in a selfless way, get more successful outcomes in the long run than those who don’t. Very relevant in business especially for roles involving Agile, product management, marketing and of course sales.

The book also covers Commitment and Consistency, Social Proof, Liking, Authority and Scarcity

If you’re into psychology, I’d recommend this book.

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).

Strategy

VMOST = Vision, Missions, Objectives, Strategies and Tactics

Each product should have a clearly defined product vision, KPIs and strategies if it’s expected for the development team to deliver outcomes/head in the right direction, and using the VMOST canvas is an effective way of showcasing what these are in a clear and concise format.

VMOST example

Vision: A passionate and exciting statement which typically should only be one sentence, where in a nutshell it should explain what your ambition is/what is your end goal of the product and who it’s for. More info on creating a compelling product vision can be found here.

Missions: In order to achieve the product vision, there would be multiple high-level missions you need to go on – what are the biggest problems which need solving before achieving the vision.

Objectives (KPIs): You can track progress of your missions through setting multiple objectives (aka KPIs), which would include metrics which are measurable.

Strategies: Initiatives which would deliver/impact the objectives (KPIs).

Tactics: Multiple ideas (Epics) which would deliver each strategy. The tactics should be laid out on the product roadmap, so there’s a nice link between the product VMOST and product roadmap.

Although the product manager is responsible for defining and owning the product VMOST, it’s important that it doesn’t happen in silo, as it takes collaboration with the rest of the business especially stakeholders/data/customers/tech to help provide some guidance on the selection of problems to solve which would be represented on the VMOST.

Once the VMOST is ready, it’s time for the product manager to showcase this in a passionate way across the business and perhaps print it out on A0 to sit near the dev team on the wall, so it can always be top of mind.

Good luck in creating your VMOST!!

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 Manager 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.

Less

LeSS (Large Scale Scrum) is an agile framework for 3-8 Scrum teams, but when there’s more than 8 Scrum teams it’s time to think about adopting LeSS Huge. So let’s look at the differences.

LeSS
LeSS is a scaled up version of one-team Scrum, and it maintains many of the practices and ideas of one-team Scrum. In LeSS, you will find:

In LeSS all Teams are in a common sprint to deliver a common shippable product, every sprint.

LeSS Huge

Less-huge

What’s the same as the smaller LeSS Framework:

  • One (overall) Product Backlog
  • One Definition of Done
  • One Definition of Ready
  • One (overall) Senior/Lead Product Manager
  • One Sprint

So what’s Different?

  • Area Product Managers
  • Area Product Backlogs
  • Area Product Vision
  • Set of parallel meetings per Area

It’s important to remember that these frameworks are just guides and every business has their own org structure, so it’s completely acceptable to mould a framework to suit the organisational structure and industry sector.

If a product is to be sustainable, tech fit, compliant and competitive it needs to have a short and long term development capacity strategy which will help to ultimately deliver the product vision.

Not having enough capacity could mean spending months / years only focusing on upgrading software versions / maintaining legacy technology or meeting regulatory requirements – not making any significant progress on getting after the product vision or surpassing competitors, having too much resource could mean that another product in the business could deliver a higher return with that resource instead, but having the right amout of capacity is important.

The product having the right amount of capacity should mean it’s possible to get after low hanging fruit, maintaining current tech whilst also concurrently getting after the next generation technology (product vision), meeting security / compliance requirements and having resource to experiment.

Understanding what the right amount of capacity should be isn’t easy, but a capacity planner will be able to help. A capacity planner should ideally be driven by points and velocity, so that no matter where the feature is on the feature pipeline (received a high level t-shirt size or has been broken down into stories) it’s possible to easily update the capacity planner with a more accurate estimate as the feature goes into development.

The data you’d typically need to lay out in a spreadsheet in order to effectively capacity plan includes:

  • Date (by month)
  • Team velocity – ‘Points to Allocate to Features’ (which already takes into account average sickness, holidays, ceremonies, breaks, training etc)
  • Forecast of future velocity based on an increase / decrease in capacity eg. Are you planning on adding another team to the product in 4 months time?
  • List of features
  • Estimates (in story points) against each feature
  • Priority order of features
  • ‘Points Remaining’ which is calculated as you start filling up the spreadsheet

It’s totally possible to roughly estimate future features by dev sprints, team sprints or man days instead of points as long as you convert it back to points after knowing how many points a whole team burns each sprint (velocity).

Another reason why it’s essential to have a capacity planner is that based on when features start and finish on the plan will drive the product roadmap dates making the roadmap data driven.

Having a capacity planner available is also a handy report when demonstrating to stakeholders that when features are in the correct priority order and once capacity has run out for a given month, then there’s no more room to slip in anymore work and it’s a case of being patient or changing priority / increasing capacity.