Archive for the ‘Guides’ Category

Marty Cagan, Partner at Silicon Valley Group gave a “Straight Talk on Product Ops” at the Lean Product Meetup in January followed by a fireside chat and Q&A.

Over 303 other product folk attended the live session wanting to hear from Marty about product ops.

Notes from the session:

  • So many companies define Product Ops differently
  • Some of the most toxic ones are taking off in some companies, important to raise the impacts so then it’s a conscious decision
  • “Product Ops operates differently at every company” – Product School, this statement is not that helpful, it’s different in every company, but some companies have similarities
  • We can’t even agree to decide what the common role of Product Manager is in the industry, so not surprised we’re in this situation with Product Ops
  • Like Dev Ops, Design Ops, people have thought cool we’re going to provide product managers with real tools to help Product get products into production quicker

More than 50 companies got in touch with their definition of how they use product ops:

  1. The Reincarnated PMO Model – product ops facilitate planning activities, they gatekeep all of the product requests – most damaging, not all that common
  2. The Two-in-a-Box PM Model – handles the day to day tasks involved with development – it’s like getting product executives to do the day to day tasks – 2nd most serious problem, splitting the product manager role from connecting customers, other areas of the business and engineers, last thing you want to do is cut that person in half, innovation goes right down, slicing the job in half is disempowered, more damaging than helpful
  3. The Delegated Product Leader Model – Product Ops ensures our PM’s learn the necessary skills and techniques needed to connect the dots between the activities of the various product teams – like a personal coach to the product managers, this is something the VP of product (head of product) should do 1:1 coaching from an experienced product leader
  4. The Production Operations Rebranding Model – Product Ops job starts when the product /feature launches making sure that things run smoothly, they’re helping more around customer service, more like customer success ops, not really focused on product, this definition isn’t a problem
  5. The Product Marketing Manager Rebranding Model – Product Ops covers two main activities: synthesizing ongoing customer feedback from sales, services and support (GTM strategy incl. beta and early release programs). This is due to politics if product marketing doesn’t have headcount but needs all this done. This method is a good thing and feels it is a good modern definition of Product Ops.
  6. The Force Multiplier Model – best one, really empowering product teams with Qual & Quant insights, product tools eg. roadmaping and best practices, would be better moved to this new Product ops team than buried in UX team – the problem is that companies are staffing this role definition with junior people, should be more like principle product manager level. So the structure should be:

CPO:

  • Product Management
  • Product Design
  • Product Ops – to empower product teams with Qual & Quant insights, tools and best practices

Nothing new in Product Ops from the different definitions, whilst The Force Multiplier Model isn’t new it’s well packaged and it came from Melissa from Escape the Build Trap. Solves the issue where UX have insights that no one does anything about. Puts the qual/quant insights squarely in product across all product managers – a more visible place where it has real value.

The two dangerous forces behind so many weak organizations:

  1. Scaling via Process rather than Leaders through people – SAFe is a good example of this
  2. Splitting the Product Manager Job – see 2nd definition above as an example, the product manager should focus on value and viability for the customer and not get involved in QA, design etc, there are people to handle this and the business should resource appropriately

One of the most common situations/questions I was asked last year was around not having time to read books and “how on earth do you find time to read so many books?”, so I’ve published this article to help others wondering the same thing.

So how do I find time to read any books, let alone so many?

  1. We don’t have a tv at home, so there are fewer distractions.
  2. We don’t have any kids yet (although this might change this year).
  3. I make it a priority because I enjoy reading about other people’s experiences, the subject of books I read I have an interest/passion in, and learning from books make a positive impact on me personally and professionally.
  4. I only ever have one book in progress at a time, always have the next one lined up, and use an Amazon wish list to manage my backlog of books. Also, I only buy physical books, nice to escape from the screen and having a book lying around is a motivator to pick it up and read it.
  5. I seem to have a thirst for learning from books since I only started reading non-fiction books at the end of 2019 for the first time since leaving college over 20 years ago, so I’ve had a lot of practical experiences to make sense of and huge amounts of wisdom to learn from. Because of this, I tend to be able to relate to what a lot of books say, which helps me absorb the content easier and makes me feel immersed in the experience.
  6. Other people reading (especially my wife) and those that share their book reviews inspire me to read more.

It ultimately comes down to priority. Anyone can find time to read books if they make it a priority and reduce time on other activities they have less interest in. Also, as you start reading and experience the impact, you’ll naturally want to increase the priority of reading books and therefore find more time to read.

If you’re reading this article, the below books will get you off to a flying start:

  1. Indistractable by Nir Eyal
  2. The Power of Now by Eckhart Tolle
  3. Atomic Habits by James Clear
  4. Unlimited Power by Anthony Robbins
  5. Making Ideas Happen by Scott Belsky

The majority of modern enterprise businesses now have a classic Scrum team setup (engineers and PO), but still wonder how they can respond to customer feedback quicker/more frequently, get ahead in the market, and innovate whilst protecting/growing revenue.

If you’re wondering this or generally interested in Agile, this book by Darrell Rigby is for you and will give you a very well balanced overview of what those next steps look like to unlock the benefits of Agile across the business, and introduces you to the concept of an Agile enterprise which allows bureaucracy and innovation efforts to coexist without the need for a big-bang approach.

An Agile enterprise involves creating Agile principles at every level starting from the top with an Agile leadership team, rather than just having an Agile tech team and the rest of the business bureaucratic. As a result, Agile Leadership is a big focus of the book and it dives into some starting points for principles:

– Employees learn by doing things themselves
– Trust is built over time
– Doing what only you can do makes everyone better off
– Customers are the best judges of what they want

To represent what a balanced approach could look like there’s a visual diagram showing an example of the agile enterprise operating model, which is fully customisable and “when you do it well, you create mission-inspired teams that work together across the organisation, both the run-the-business and the change-the-business elements”.

There’s plenty of inspiring success stories from Bosch, Amazon, Spotify and RBS too.

“More agile is not always better agile. There is an optimal range of agility for every business and for every activity within a business.”

“Genuine customer obsession sets a strong foundation for agility.”

View the book on Amazon here.

Here are some techniques to help you decide on what to read and do to improve:

1. Read a book that is relevant to a situation that you’re in now eg. Removing some bad habits, time management, reducing anxiety, understanding the full breadth of product management, levelling up your career, producing a product roadmap, putting together a product strategy, defining a compelling product vision, prioritisation, scaling a business from start-up, conducting customer interviews, improving soft skills, handling conflict, struggling to influence… and then try out the various tools or ideas you’ve learned in the book. Reading a book that is relevant to your current situation will likely help you absorb the content easier too, enabling you to extract even more value from it. There is a book for every situation nowadays, just search on Amazon and you’ll be surprised at what you find.

2. Conduct basic gap analysis in your knowledge/skills and read books on the gaps, then try out the ideas you’ve been exposed to. A performance review at work/feedback from colleagues is also a good source of insight on what to focus on.

3. Validate some of the nonsense you might be experiencing. If you’re experiencing a situation that seems a bit bonkers or you’re wondering whether there could be a more effective way of doing things, read a book with good recommendations that are always backed up by thorough analysis and then read some more similar books on the subject to further validate or increase your knowledge in the area. If several high profile authors are saying similar things and you’re experiencing the opposite, it’ll give you the confidence to question existing ways and in time help steer the ship in a more successful direction.

Now, if you’ve not got that opportunity at work to build up some practical experience of what you’ve learned (eg. If you haven’t got the autonomy or someone else does it) do it on the side or in your own time as an example/exercise and get feedback internally at work or from a mentor which will produce an extra benefit of being seen as being proactive and showing initiative. If you’re in an unhealthy culture where you’re not given room to experiment on your learnings, it’s likely time to seek haven in a more healthy culture.

On the other hand, if you’ve spotted a gap where something isn’t being done which you’re not directly responsible for, step up and try and fill that gap yourself whether it’s roadmapping, making a feature backlog more visible to stakeholders, market analysis, value stream mapping, reduce waste…

If you still aren’t sure where to start, the below books in that order should help get you off to a flying start:

  1. Power of Now by Eckhart Tolle
  2. Start With Why by Simon Sinek
  3. Atomic Habits by James Clear
  4. Unlimited Power by Anthony Robbins
  5. The Mindset of Success by Jo Owen
  6. The 7 Habits of Highly Effective People by Stephen Covey
  7. Indistractable by Nir Eyal

As Sarah Wood says in her book Stepping Up “the most important thing is that you get started, as quickly as possible. Done is better than perfect!” which also applies to both reading and doing.

Enjoyed this read by Scott Belsky where he uncovers a pragmatic set of techniques to help organise, prioritise and execute actions turning high aspirational goals into reality, gives tips on collaborating with other people to help accelerate progress, and provides good insight into effective leadership and self-leadership methods.

“Genius is 1 percent inspiration and 99 percent perspiration”

“To push your ideas to fruition, you must develop the capacity to endure, and even thrive, as you traverse the project plateau.”

“Making ideas happen boils down to self-discipline and the ways in which you take action.”

“Even when the next step is unclear, the best way to figure it out is to take some incremental action. Constant motion is the key to execution.”

“Nothing will assist your ideas more than a team of people who possess real initiative.”

A practical short read on how to properly talk to customers and learn from them by Rob Fitz.

Whilst the book focuses on validating new product/business ideas, many principles Rob talks about still apply to existing products, enabling you to understand how and why customers are using the product in the way they are and how they feel about the product vs. competitors – building up qualitative data about the UX.

Even though the book was published 8 years ago, it’s still relevant and I loved how the book focuses on having an informal chat with customers about their feelings and why first, before diving into getting feedback on solutions which you’d do in future conversations – how can you satisfy customers if you don’t understand them first. Also, with remote customer interview tools now available like User Zoom, Lookback and User Testing, it makes it easier more than ever to talk to customers weekly.

The Mom Test:

1. Talk about their life (or how/why they use the product in the way they do) instead of your idea
2. Ask about specifics in the past instead of generics or opinions about the future
3. Talk less and listen more

It’s called The Mom Test because it leads to questions that even your parents can’t lie to you about.

Link here to the book on Amazon.

It’s also a great companion to Lean Customer Development by Cindy Alvarez.

This is the best book I’ve read on DevOps and it follows on nicely from Gene Kim’s other book The Phoenix Project.

It’s quite easy to think that DevOps practices are just something that dev teams deal with and the value is simply just an increase in throughput, but the book provides clarity on the colossal value that adopting a DevOps culture and the principles can have on teams, the business, and customers.

Throughout the book, Gene echoes the importance of having the whole product team (product manager, designer and several engineers)) involved in the transformation, as well as focusing on outcomes, and to achieve outcomes you need to collect data and learn through experimentation which is covered in the book too.

Gene gives good advice that it’s important to avoid funding projects and instead you should fund services and products: “A way to enable high-performing outcomes is to create stable service teams with ongoing funding to execute their own strategy and road map of initiatives”.

This is the most comprehensive and practical DevOps guide out there and the layout makes the content easy to digest. The book covers:

– History leading up to DevOps, and Lean thinking
– Agile, and continuous delivery
– Value streams
– How to design your organisation and architecture
– Integrating security, change management, and compliance

The principles and tech practices of:
1. Flow
2. Feedback
3. Continual Learning and Experimentation

“Our goal is to enable market-oriented outcomes where many small teams can quickly and independently deliver value to the customer”

Previously ‘Product Management’ as a function has been part of the tech or marketing department and it’s still a relatively new concept to have Product Management as a separate department in an organisation.

As a result, there are many common misconceptions that the main function of Product Management and the Product Manager/Owner is to define features themselves and work with tech to deliver them, making it somewhat frustrating when marketing, insights, commercial team or any other department outside of product make a request which takes up tech effort which could have otherwise been spent on pushing your own changes.

So if this is a misconception, what is the role of Product Management in the wider organisation?

Product Management as a function/department sits in the middle of the organisation where the Product Manager is a generalist who collaborates with the specialists across the business to help manage the product business and develop the product, which includes working with:

  • Technology / DevOps and Designers/UX to learn through experimentation and reach outcomes early and often by developing the product continuously
  • Marketing to grow the product
  • Customer support to help them provide an A* customer service
  • Legal / compliance team to ensure the product is compliant
  • PMO / Project Managers to support them on cross-cutting high-value initiatives
  • Commercial / Bus Dev to take advantage of opportunities
  • Data / Insights team to gain access to qual/quant data, learn and understand how you can use data better to deliver more effective outcomes
  • The C-suite especially CEO to understand the business goals and ensure your product goals aligns with them
  • Yourself, the market and customers to analyse qual/quant data to find out what problems there could be to solve

As a Product Manager, you may feel overwhelmed by a sudden bombardment of requests coming from certain departments all of a sudden for example marketing requests, and a positive way of looking at this is that these inputs are essentially all just product ideas and part of qual/quant data analysis to help improve the product/product business which as a Product Manager you need to manage.

You may also find that you are spending the majority of tech resources on marketing requests for months, which is absolutely fine, if this is the highest priority work – the importance of growing the product business should not be underestimated.

With lots of valuable input incoming at a frequent rate, as a Product Manager, it means that you need to be organised, proactive and utilise your emotional intelligence to ensure you get the most out of everyone and that you handle situations rationally. What will help you is:

  • Accepting and believing that you are one team working together to improve the product/product business
  • Having a tidy data-driven prioritised product backlog which anyone can access
    • This will make it easier to say why someone can’t have what they want now!
  • Presenting your product roadmap, successes and what’s up next to key stakeholders on a regular heartbeat, but also ensuring that stakeholders have access to real-time updates of the product roadmap. Aha.io is a great tool for this
  • Know your customers, market, product strategy, backlog and data, so you can be assertive and lean into tense situations – Managing Product = Managing Tension is a great book to help give you confidence to lean into tension

A Product Manager is accountable for the success of their product and therefore also needs to manage the product business, not just develop a product.

Steven Haines is a globally recognised expert in Product Management who has done incredible work professionalising Product Management. I’d recommend reading the below books of his:

As Haines says “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).”

A PRD (Product Requirement Document) helps a product manager write a story on how to get from problem -> solution methodically. Often problems can be so big, complex and have ambiguity that it’s hard to know where to start, so a PRD will help you rationally approach the problem and get the support you need to reach an efficient and effective outcome.

It’s important to point out that it’s not necessary to:

  1. Use a PRD for every single problem/idea, normally only for epics/initiatives/features/medium or large-sized items.
  2. Complete the whole document, only fill out bits you need, you may find that you only complete the problem/value and hypothesis parts.
  3. Work on it in a silo. You will achieve a more efficient and effective outcome if you get the rest of the product team (designer and engineers) and stakeholders involved at the beginning in a workshop format so that you can work as one team across the discovery phase.

A good place to create a PRD is in Confluence, so it’s easily accessible across the business allowing colleagues to easily comment remotely. I’ve also used Google Docs previously and copied some of the information into the epic of JIRAs to reinforce the problem we are looking to solve/projected value we are looking to get after to the development team.

The first few PRDs you write you might find it quite slow whilst you work out how to get hold of the qual/quant data, but you soon pick up speed as you become familiar with the key elements of discovery and have the data already accessible at your fingertips.

It would also be helpful for new starters if you add a completed example of a PRD to the top of the PRD template which will help add some context for them. Some PRDs can be quite lengthy if the problem is big, complex and has a lot of ambiguity, so it’s worth adding a table of contents at the top making it easy to navigate through the document.


Including a list of people who are involved:

RoleContact
Product Manager. <tag person/<name>
UX/Design<tag person/<name>
Technical<tag people/<names>
Stakeholders<tag people/<names>
Jira/Design/Helpful Links <tag person/<name>

Problem/Value/Idea

A description of the problem or idea along with projected value if you have this. This is a good chance to spend quality time digging into the problem to build up a business case using qual/quant data.

  • Idea: Supporting Dark Mode in our apps…
  • Problem: Our iOS app is currently a 3* rating and Android app 2*, with the top problems being…
  • Problem: 70% of our customer support queries relate to promotions which cost us £x / month
  • Problem: Our day 1 churn rate is higher than we expect…
  • Problem: We currently release new software iterations monthly, rather than daily…
  • Problem: In the latest customer survey, 10% of respondents report the product being slow and unstable…
  • Problem: 20% of customers don’t feel rewarded for their loyalty
  • Problem: Our total marketing communication engagements have gone down since complying with the new GDPR regulations, making it harder to talk to customers frequently
  • Projected Value: Saving customer support costs by £
  • Projected Value: App rating > 4* resulting in healthier ASO and raking and therefore an increase in organic installs creating 20 new customers a day
  • Projected Value: Day 1 churn rate under 20% resulting in £xx revenue increase
  • Projected Value: New customer conversion rate > 30% resulting in £xx revenue increase

Hypothesis

List out one or more hypotheses you come up with to test out. This is a great opportunity to collaborate with the whole product team (designer and engineers) and stakeholders, not only to compile the list of experiments but also what data you need to learn and what tools you might need to execute the experiments.

  • Providing existing customers with the ability to refer their friends will increase new customers incremental by 10% worth an extra £xx revenue increase
  • Having a stepped registration form will increase the registration rate by 10%
  • Solving all customer queries in the app store and responding to every app store review within 3 hours will increase customer satisfaction and therefore our app store rating, which will in turn help ASO and our app store ranking

KPIs

  • Volume of engagements with feature x
  • Conversation rate
  • ARPU
  • CPA
  • Retention rate
  • Day 1 churn rate
  • LTV
  • Registration rate
  • Crash levels
  • Deposit elapsed time
  • Session time
  • Login elapsed time

Market Analysis

If you have competitors who have solved the problem already, this is a good place to document the UX. Also, detail your target personas and other details about the market which will give you a better idea of who the product iteration is for.


Customer Research / Validation

Detail any qual/quant data you have gathered relating to the problem/idea eg. customer interviews, financial/engagement data, trends, and any historical experiment results which are relevant.


Constraints

  • Regulatory live date of x
  • Marketing tv campaigns going live x
  • Low front-end development capacity
  • Utilising platform/tool x
  • Time to market
  • Dependencies on teams x

High-Level Requirements / Use Cases

This shouldn’t be at user story level (detailed spec), but instead, just an idea of customer flows/use cases and considerations covering:

  • Functional
  • Non-functional (since the rise of DevOps, this gets covered as BAU/as part of development in most cases)
  • Customer support
  • Marketing
  • Tracking

Flow

Embed a mock-up, flow, UX or prototype.


Risks

  • Lots of ambiguity, so it could take a while to reach the desired outcome
  • Other higher priority work could mean that we don’t have the tech capacity to get the solution to market in time to reach the optimal outcome
  • The problem may not be such a big problem when we go to market
  • We may only solve part of the problem because of x
  • It could take more than 3 months before we learn because of x

Technical Considerations

  • We have plans to replace the existing platform in the next 12 months.
  • We need to conduct an RFP on tooling
  • This is the first time we are conducting experiments, so we need to considering process and tooling

Go-to-market Strategy

This is where you can detail the elements you need to consider/action to have a successful go-live covering:

  • What product support marketing require to market the product iteration effectively
    • Special promotions
    • Signposting across the product
    • Training, user guides
  • Customer support training
  • Release preparation to coordinate with any time-sensitive fixed timeframe marketing campaign especially TV ads
    • Day 1 plan
    • Feature switch process
  • Regulatory approval
  • Production access for end-users

Q&A

Adding a question and answers section at the bottom allowing you to add notes from meetings and tag anyone responsible for answering the question.

QuestionsAnswers

If you’re an empowered Product Manager / Product Owner who has the authority to shape the strategy of your product and need insight into effective product strategy/roadmap practices and frameworks, this book by Roman Pichler is for you.

The book is well balanced giving you guidance on when and when not to use particular practices, for example when a product is yet to be validated in the market and therefore has not reached product-market fit, you shouldn’t spend your time making up a roadmap when you should be spending time experimenting and talking to target customers.

However when you’re scaling or have a mature product then product roadmaps would have many benefits which are explained well and are very accurate, such as collaboration, alignment and generally showing how you plan to progress towards your product vision.

I particularly liked The Strategy Canvas which looks like a great tool for competitor gap analysis.

The practices and frameworks are explained in enough detail that even if you’re not empowered to shape the strategy of your product, you could still find this book beneficial by understanding the tools and proactively having a stab at using them for your product.

Pichler leaves no stone unturned as he covers every aspect of product strategy from idea to execution, which ultimately enables product management functions to operate effectively.

Image source here.

Is there a way to get value into customers’ hands early and often?

Is there a way to deliver high-quality software on time, every time?

Is there a way to innovate at scale as the company grows?

Absolutely yes to all of these questions and Roman Pichler explains how this is possible in under 120 pages in this book.

Whilst there has been a huge uptake in businesses adopting Scrum – the most popular Agile framework over the past decade, some are still asking these questions after falling into various pitfalls, where Pichler addresses them all eloquently in his book, for example:

• Having too many handoffs of requirements/solutions/decisions which disempower the Scrum team
• The product owner only focusing on tactical work
• Not coaching product owners to set them and the Scrum team up for success
• Focusing on outputs over outcomes

If you are currently playing the product owner role, can relate to any of the pitfalls above and would like a mentor to help fill in your knowledge gap, DM me and we can solve it together whether it’s mock customer interviews, working with qual/quant data, time management, roadmapping, prioritisation, how to define a vision, missions, objectives and strategies for a product or any challenges you’re facing.

This book is an essential read for CPOs who are still struggling to experience the benefits of Agile, as well as anyone who’s playing the product owner role.

This is the best book I’ve read on #Lean.

The #LeanStartup and The Startup Way by Eric Ries were also great reads, but this book by Cindy Alvarez is a condensed version of both of them with practical step by step guides on execution, where no gaps are left when it comes to understanding how you can build products in an efficient way that customes will buy.

Whether you’re in a large enterprise with existing products or a startup, Cindy provides great examples of the benefits of using Lean principles to streamline your product development process in order to deliver more value.

This book is for:

  • Product managers, designers, and engineers who want to increase the chances of building a successful new product or new feature
  • Product-centric people in large organisations who are struggling to help their organisations move faster and work smarter
  • Entrepreneurs seeking to validate a market and product idea before they invest time and money building a product that no one will buy

Since the pandemic has caused more people to install webcams and with innovative solutions like UserZoom and Lookback to connect, it makes it easier more than ever to validate hypothesis and speak to your customers weekly to gain valuable insights.

There’s a lot of confusion around product management job titles, seniority, and hierarchy. This has become more prominent since organisations started creating the Product Owner job during their Agile transformation using the Scrum framework, even though Product Owner is a role that a Product Manager plays rather than a job in itself. This makes it hard to compare jobs, plan your career, and attract the right talent to your team.

Inspired by Mind the Product, in this article I’ll walk through the product manager levels, providing overviews for each product role, and some useful content to refer to.


Associate Product Manager (APM) / Product Executive

This is an entry-level product position, for someone who is brand new to the role.

An APM can be a recent graduate who would enter into a rotational apprenticeship program across the business. The aim—similar to most apprenticeships—is to develop these candidates into full-time positions through a combination of training and hands-on involvement with real projects.

Alternatively and the most common route, an APM has some work experience under their belt already and can come from any background. Engineering, marketing, design, or commercial are the most common backgrounds.

The APM works with a product development team under the leadership and mentorship of a product manager, where they would focus on learning the full breadth of the Product Manager role whilst on the job.

Typically an APM would need 3-5 years of experience before progressing to the next level as a Product Manager.


Product Manager (PM)

The most common job title of a product manager can span a wide range of experience, responsibility, and skills. Broadly this is someone who operates independently, leads the work of a product development team, and is responsible for a product line or customer journey. Because it’s the most common title, it’s important to consider what product they manage.  For example, if they’re a product manager for Facebook’s news feed and impact billions of users, they’re probably more senior and experienced than a product manager at a brand new startup.

To be clear, the Product Manager is fully accountable for the success of their product line, so as well as defining the product vision, KPIs, strategies and product roadmap for their product line, they would be part of an Agile team managing the product backlog and working with the engineers to execute the product backlog items (PBIs) and test hypothesis.

For some insights on the Product Manager role see ‘How do you Become a Product Manager?’ by Liam Smith and discover what it is that Jase Clamp believes really makes a Product person in ‘What’s in the DNA of Product People?’.

Similar to the APM role, after 3-5 years as a PM you can expect to take the next step to become a Senior Product Manager.


Senior Product Manager (SPM)

A senior Product Manager does the same thing as a product manager but has a senior title either in recognition of their contributions, the relative importance of their product, or reflects the fact that they also spend time coaching product managers. The Senior Product Manager is hands-on with a product line and also has some line-management responsibilities.

Once you’ve been a PM/SPM for at least 7 years and at least 2 of those has involved line managing/coaching other PMs, then you’re ready to take the next step up to be Lead Product Manager.


Principal Product Manager (PPM)

This is a newer role, and usually a very senior product manager who is responsible for a critical product in the company. This can be equivalent in rank to a Senior Product Manager through to a VP Product. The difference is they are not managing other product managers at all — they are simply exceptional product managers who want to stay hands-on and leave people management to others.

In many ways, this is similar to the Architect track in engineering (in contrast to the CTO track), and something we should encourage more. Just because you’re a great product manager and want to advance in your career, it doesn’t mean you should have to move away from being a hands-on product manager to a leader of other product managers. Some people are just better suited to one path than the other. Recognising who is great at leadership and who is great at building amazing products is equally important and valuable to an organisation.


Product Lead / Lead Product Manager / Group Product Manager

This role is more common in larger companies with more products and management layers. Whilst this role does focus on managing other product managers, a significant amount of time would be spent supporting/coaching Product Managers with their product line vision, strategies, market analysis and execution, helping improve the product organisation structure, leading Lean initiatives to reduce waste across the business and work on cross-product line strategies.

At this level you’d have been exposed to working across multiple product lines, line management/coaching PMs and being even more dynamic, so after 3 years of being at this level, you’d be ready for the Product Director / Head of Product role.


Product Director / VP Product / Head of Product

This is where the role fully goes from an individual contributor, to someone who has stepped back from the day-to-day to focus on leading other product managers and working on alignment. This is where soft skills around people management become a critical part of the job.

After being a Product Director for at least 3 years, it’s time to take the final step up to be the Chief Product Officer.


Chief Product Officer (CPO)

A Chief Product Officer is the most senior product person in an organisation. They usually manage more than one team of product managers and represent product in the C-suite or management team. They’re responsible for overall product strategy and alignment within their teams and with other parts of the organisation.

The difference between a VP Product and CPO in smaller companies isn’t huge, and the title is used interchangeably for the most senior product person in the company. But in larger organisations that have both roles, we can again borrow from our engineering friends to clarify the difference. The VP Product is responsible for the team, the processes, and getting things done, while the CPO is responsible for the overall product vision, product architecture, and overall organisational alignment.

In ‘Where Does Product Fit? What’s Being a CPO Really Like?’, Zoopla’s CPTO Dave Wascha shares his take on the reality of the CPO role, where Product fits within the organisation, what skills product managers need to be successful, and more. You can also learn how Ashley Fidler went from a PhD in Linguistics to a CPO at Eigen Technologies in her instalment of How I got my job.


One size does not fit all

Most companies don’t need all these tiers of course, so it’s important to think about how this fits into your organisation. At a startup, you might have a single Product Manager. As you grow, a couple of Product Managers could report to a Head of Product/VP Product. Only as the company grows and the suite of products grows do you need to consider more layers. As with anything else in product, these team structures and tiers should be aligned with customer needs. This way, you can incentivise and organise teams in alignment with your company goals.

Structure = Clarity

Having clear and common structures for product management job titles in our teams will help us all better understand our careers, roles, and teams. This structure should provide the right foundation for you and your teams to ask: Do your team’s titles accurately reflect their jobs? Are they clear enough that applicants looking at your open vacancies know what you’re hiring for and if the job is for them? Or do you need to rethink your structure to maximise clarity?

The most common Agile framework is Scrum, which typically involves a product manager managing a backlog of user stories (outputs) using the user story framework:

Template

As a… <persona>

I want… <intent>

So that… <benefit>

Example

As a player

I want to be able to easily access new games

So that I can have fun playing the latest games that I haven’t played before


Since user stories are output-focused rather than outcome-focused, it becomes easy to fall into the build trap of delivering output after output with no understanding of whether it delivered any value to the customer or business. One of the reasons is that unless tracking is part of the DoD, to track the value would often require additional tracking user stories in the product backlog which are easily ignored when in a project led environment or when there is pressure to get after delivering a new unrelated user story (output).

Now, In the 1920s, Ronald Fisher developed the theory behind the p value and Jerzy Neyman and Egon Pearson developed the theory of hypothesis testing, which as a result formed an Agile/Lean technique called Hypothesis-Driven Product Development which is outcome-focused, delivers a measurable conclusion and enables continued learning. A hypothesis framework consists of:

Template

We believe… <capability>

Will result in… <outcome>

As measured by… <KPI>

Example 1

We believe that by providing players with an easy way to access new games

Will result in an increase in game plays

As measured by a higher number of game plays per player and new game engagement

Example 2

We believe that by offering new players a 5 day achievement-based promotion

Will result in new players retaining longer

As measured by a decrease in churn rate by 5%


The immediate benefit of using a hypothesis-driven framework especially for uncertain product iterations is that the product team are forced to ensure that the outcome is measurable before delivering the output/feature. Since it will be measurable, it will be possible to learn and validate the hypothesis aka validated learning.

The ideal scenario would be to run multiple experiments concurrently to reach the same outcome so that you can learn quicker (rapid experimentation). A test failing means progress, that you’ve learned what doesn’t work, so you can progress in a positive way to experiment on a different idea to solve the problem.

It’s easy to migrate from the Scrum to Kanban framework or vice versa, but migrating to the hypothesis-driven framework is significantly more challenging as it involves a culture of empowerment and learning, with trust and patience being critical elements to start with whilst the team gets used to the new framework, data structure and the validation capabilities, which is needed before the product team can conduct rapid experiments effectively.

If you are entering a mature market and you are more certain that the solutions will solve the problem, a standard user story is more appropriate, but the most efficient way of delivering outcomes where you are uncertain that the solution will solve the problem is hypothesis-driven product development, rather than spending months guessing with user stories without any learning.

With tools available to easily conduct remote customer interviews (UserZoom, Lookback.io), A/B testing (Firebase, Maxymiser) and prototyping (Sketch, Figma), it makes it easier more than ever for empowered product teams to efficiently conduct experiments to validate that the solution will solve the problem.

Good luck in your experimentation journey!

Bubble: Bitcoin (Crypto) becoming a mainstream payment method and that Crypto is decentralised.

Revolution: Private blockchains used to improve supply chain efficiency for businesses and Crypto being a viable investment, as well as used as a payment method for large/international transactions.

Walmart used IBM’s Food Trust private blockchain to improve the efficiency of their supply chain making over a hundred thousand-fold speed improvement from farm to Walmart. Microsoft with the Xbox also made significant efficiency gains by implementing the same private blockchain strategy to improve the royalty settlement and new publisher flows.

Microsoft Azure, Amazon Web Services, Oracle, Google Cloud and IBM already offer private blockchain solutions.

Zynga, Etsy, Microsoft, Burger King, KFC, Virgin, Expedia and many others already accept Bitcoin payments.

The stock exchange industry could save $20 billion from blockchain-based clearing.

There is 1 in 66 billion trillion chance of someone mining a block (which is used to validate transactions and receive a Bitcoin reward for their effort).

Whilst only 21 million Bitcoins will ever be available (3 million left to mine), each Bitcoin is equal to 100 million Satoshis, with a Satoshi being the minimum amount you can exchange, making it an investment for everyone.

To verify a single Bitcoin transaction uses enough electricity to power an average household for 22 days and generates the same carbon footprint as over 750,000 Visa transactions.

In order to mine, you need a mining farm (a set of super computers) which are primarily owned by a small group of people that are employed and funded by a single company. Also China owns 80% of the market for Bitcoin mining hardware which is being integrated with the monetary system, adopted by banks, and regulated by governments…so not so decentralised.

Bitcoin can only process about 3 transactions per second, Ethereum 15 per second and Visa 45,000 per second.

To send $10 from US to Indonesia it’s impossible via bank transfer, costs $30 via UPS and only costs $1 via Bitcoin. To send $10k the fee is $400 via bank transfer, $150 via UPS and still only $1 via Bitcoin. In fact, it would still be just $1 fee via Bitcoin if you was to send $10m whereas the fee via bank transfer would be $400k.

Crypto exchanges already support KYC and AML regulations, making it  ready for iGaming and other highly regulated industries.

“The two biggest use cases for crypto going forwards will be payment methods (primarily for large or international transfers) and investments (supplementing, but not replacing, stocks and bonds).”

In this book, Neel Mehta, 🚀 Adi Agashe and 📍 Parth Detroja break down this highly complex set of tech into a digestible, balanced and comprehensive guide, which I’d recommend to anyone who doesn’t know about the benefits, challenges and future of blockchain and cryptocurrencies.

Lastly it was nice to hear that the creator (Satoshi) of this innovative tech is a fellow Brit.

Vision

It’s worth spending time creating a compelling vision statement because it’s something that will be repeated over and over again as it’s the key driver to drum up excitement, passion, investment, confidence and trust that the product direction is aligned to the business, solving a real problem and then, in turn, delivering significant value for the business and customers.

First things first, craft your vision statement which should only be one clear sentence, wherein a nutshell it should explain what you’re looking to deliver, to who and why:

Vision statement

Then create a product vision board specifying who the target market is for your product, problems the product solves, clarifying what the product is and how the product is going to benefit the business and customers:

Vision board

Lastly, having a vision diagram is a great way of providing stakeholders and the business with a visual image of the status of the product capabilities of where you’re at with the product today and where you’re heading. Having colour coding for ‘live’, ‘in progress’, ‘planned’ and ‘to do’ would cover it – there are plenty of mind map tools to help you visualise your product, one of which is Lucidchart which comes as a plugin for Confluence also. It’s important to keep the product diagram focused on high-level features rather than detailed technical solutions around systems as that would be more of a technical architectural diagram:

Vision diagram

Having a solid product vision isn’t just to help the business allocate resource, but it’s also essential for the development team to know exactly where they need to head and why.

Once you have a compelling product vision, it’s time to find out how to get there by creating your VMOST!

Once you’ve defined a compelling Product Vision and VMOST, you will need to map out the ‘what’ and ‘when’ and the Product Roadmap is a great way of visualising the journey.

The Product Roadmap is also a good way of managing expectations with stakeholders, a great visual to collaborate over and view dependencies, as well as giving assurance to the engineers that you do have a well thought out data-focused plan rather than changing your mind daily based on who shouts the loudest.

Key points of a Product Roadmap:

  • It should be at a high-level eg. Epic, feature or iteration level – Epic level is a preference as then it maps nicely to the teams’ product backlog items (PBI) under the epics.
  • It needs to include dates spanning the next twelve months whether monthly or quarterly.
  • The bars on the chart show when items start and when the development will be complete (live hidden).
  • One of the most important things is to educate development teams and stakeholders that the drop dates are an intent (not commitment) of focus/delivery and that things will change, so it’s advisable to avoid spending significant amounts of time making each item exact, as the desire from the business would be to have a rough idea of the twelve-month view rather than knowing whether something starting in six months will be delivered exactly a month later than that for example.
  • The roadmap needs to be easily accessible by anyone in the business where they can use their network login and can also access it from outside the office eg. on the train – if it’s hard to access, people just won’t view it and assume there’s no plan.
  • It needs to be updated frequently – if it’s regularly out of date, again people just won’t access it.

Product Roadmap examples

Roadmap sample 1

Roadmap sample 2

The most important purpose of the Product Roadmap is for you to provide a sign of intent for when product items will be delivered over the next twelve months (your journey to reach your goals/product vision), with the keyword being ‘intent’ here ie. Not an exact drop-dead delivery date. Product Managers with experience of the teams’ velocity could use gut feel also which is acceptable or rough t-shirt sizing from the lead developers, rather than dragging the dev teams away for hours/days to roughly size big pieces of work which will either 1. Change anyway and 2. Be extremely inaccurate as unknowns result in estimates going through the roof.

Strategy

VMOST = Vision, Missions, Objectives, Strategies and Tactics


Each product line 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 framework of showcasing what these are in a clear and concise format.

Vision: An inspiring statement which typically should only be one sentence, wherein 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: To achieve the product vision, there would be multiple high-level missions you need to go on – what are the biggest problems that need solving before achieving the vision.

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

Strategies: Initiatives that 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 managing the product VMOST, it mustn’t happen in a silo, as it takes collaboration with the rest of the business especially stakeholders/BI/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 evangelise this in a passionate way across the business and perhaps print it out on A0 to sit near the Product/Agile Team on the wall, so it can always be top of mind.

Good luck in creating your VMOST!!

Lean

A product team is never short of customer problems to solve or ideas to validate, so if there are activities in the idea -> customer flow which are wasteful, then this impacts delivering customer/business value, motivation and time to market.

In the middle of the 20th century, Toyota created an efficient manufacturing concept called Lean which grew out of their Toyota Production System. It is based on the philosophy of defining value from the customer’s viewpoint and continually improving the way in which value is delivered, by eliminating waste or anything which does not contribute to the value goal.

The core 5 principles for adopting a Lean way of working for a digital product are:

  1. Define Value – Understand and define what is valuable to your customers.
  2. Map the Value Stream – Using your customer’s value as a reference point, map out the activities you take to contribute to these values throughout the idea -> customer flow. Also map out all of the activities which don’t contribute to delivering customer value which is essentially waste and should be reduced as much as possible.
  3. Create Flow – Once you have removed the waste from the value stream, the focus should be on ensuring that the remaining activities which are valuable, flow smoothly without interruptions or delays, with some strategies including: DevOps practices, automation, breaking down steps, creating cross-functional departments and training employees to be multi-skilled and adaptive.
  4. Establish Pull – The goal of a pull-based system is to limit your work in process (WIP) items while ensuring that your highest priority customer Product Backlog Items (PBIs) are in a ready state for a smooth flow of work. By following the value stream and working backwards through the idea -> customer flow, you can ensure that your product development will be able to satisfy the needs of your customers.
  5. Pursue Perfection – Every employee should strive towards perfection while delivering products that customers needs and love. The company should be a learning organisation and always find ways to get a little better each and every day.

Some examples of my experience on reducing waste to deliver more customer value:

We introduced DevOps, where we optimised our release pipeline making it 83% quicker to deploy software updates to the team environment and 92% quicker to deploy builds to live.

We reduced the time to market for a new website from 18 months to just 4 weeks! This was achieved by identifying waste through value stream mapping, then using that analysis to simplify the code base and reconfigure some of the hard coded elements of the code (waste) to make them remotely configurable through a CMS.

The last example had the most impact where we merged a floor of front-end developers with a floor of back-end developers to create cross-functional high performing teams.

Good luck in your journey to become Lean!