Archive for the ‘Data’ Category

Product Direction: How to build successful products at scale with Strategy, Roadmaps, and Objectives and Key Results (OKRs)

Posted: Apr 16, 2023 in Book Reviews, Data, Leadership, Product Management
Tags: , , , , , , ,
0

A well-balanced, accurate, and modern data-driven approach to Product Strategy and Roadmapping. Nacho Bassino’s hands-on product experience came through as he tackled all of the controversial points raised across the industry with product strategies and especially product roadmaps – now, next, future vs. dates. There wasn’t anything I disagreed with, everything was spot on, and this book is a testament to how far the industry has come over the past decade.

“By going everywhere, we were going nowhere. We didn’t have a problem with resources; we had a problem with focus.”

“Obtaining data about the user, business, market, competitors, macroeconomic conditions, and so on should be an ongoing process for an empowered product team.”

“Your product roadmap is the prototype for your strategy.” – Todd Lombardo

“We don’t hire smart people to tell them what to do. We hire smart people so they can tell us what to do.” – Steve Jobs

“Outcome-orientation is the single most crucial transformation a product organisation can make, and the strategic roadmap can be a keystone artifact to achieve it.”

How can Product Managers encourage more teammates to use data?

Posted: May 6, 2022 in Business, Data, Product Management
Tags: , ,
0
How can PMs encourage more teammates to use data?

It was a pleasure to contribute to this article on how Product Manager’s can encourage more teammates to use data. Full article can be found here.

“Working with data helps companies across the board to unlock their potential and become more productive and better at making decisions. However, making people in the team and company rely on data involves a lot of work. Product managers must often set a strategy, reinvent processes, and change organizational behavior. 

To find out how to make more people in the team use data in decision-making and daily work, we spoke to product managers from different companies and industries. Their answers provide insights about the following:

  • Which members of product teams can benefit most from using data? 
  • What are the key barriers to using data by all members of your product team? 
  • How to overcome the barriers mentioned above? 
  • What specific tactics can help to increase the adoption of data use in a product team?
  • Which tools and apps are helpful for product teams? 

Q: Which members of product teams can benefit most from using data?

Data is helpful to each and every member of the product team. Using a data-driven approach will make it easier to understand your customers, analyze metrics and anomalies, prioritize features, and be objective about decisions.

Let’s dig deeper into different roles in product teams using data:

Gavin Deadman (Lead Product Manager, Betfair at Flutter Entertainment Plc)

As product designers and developers conduct experiments to validate the impact of a product change, it will be crucial for them to first make sure they can measure success and then monitor the data as it goes live. Otherwise, it will be impossible to understand the ROI and celebrate success.

Q: What are the key barriers to using data by all members of the product team in your experience? 

Data can help improve decision-making, gain competitive advantage, and transform the way the business operates. However, achieving these benefits can sometimes be challenging.

Based on PMs’ answers, product teams face three primary challenges to make their teammates use data:

  1. Building a data culture
  2. Consolidating data from different sources and making it accessible 
  3. Providing quality of data and training in data interpretation 
Gavin Deadman (Lead Product Manager, Betfair at Flutter Entertainment Plс)

All transactional, analytical, and qual data should ideally be in one tool, making it easy to access. Also, the speed of pulling the data is important. If data takes more than 10 seconds to load after each query it discourages people from using the tools.

Q: How did you overcome the barriers mentioned above? 

As a product manager you should break silos, create a data-driven culture, and encourage members of your team to learn and provide accessible data.

Here is what the product managers we spoke to recommend: 

Gavin Deadman (Lead Product Manager, Betfair at Flutter Entertainment Plс)

It’s helpful to prioritize the need to have front-end analytical data to connect to transactional data in one system and ask for updates weekly. Mentioning the impact helps to drive action.

Q: Can you share specific tactics that helped you increase the adoption of data use in your team?

There are some practices that can help product teams overcome the barriers to using data.

Our experts had the following key recommendations:

  • Ask right questions to uncover challenges you’re facing and generate better solutions
  • Use different KPIs to track the team and the product effectiveness and review core metrics on a regular basis
  • Encourage team members to share and discuss data
  • Set tools and processes for self-service data analysis
  • Lead by example in the workplace
Gavin Deadman (Lead Product Manager, Betfair at Flutter Entertainment Plс)

One of the best things which has helped the team use data more is asking better questions to drive action. What do users think when there are multiple design options to choose from? How can we measure success? How will we measure the impact of product development work once we go live? What are our product’s strengths and weaknesses in the market? What are our top-10 customer support queries and how can we reduce them? What data do we have to inform us that the proposed solution will likely solve the problem?

Q: Which tools and apps are helpful for product teams to increase data usage in decision making? 

Special tools and apps can help product teams use data to assess their development efforts, optimize performance, remove roadblocks, and increase customer satisfaction. Such instruments provide access to different types of data, and they have a modern infrastructure, high speed data access, and other capabilities.

The PMs we spoke to recommended these tools and apps for product teams to increase data usage in decision-making:

  • Tableau
  • Databricks
  • Snowflake
  • Excel or Google Sheets
  • Firebase 
  • Looker
  • Amplitude
  • Google Data Studio
Gavin Deadman (Lead Product Manager, Betfair at Flutter Entertainment Plс)

My favorite tool is Tableau. Its data visualization options and data access speed are fantastic if architected appropriately, and it’s quite easy to load different types of data from different sources whether from the transactional DB, Google Analytics, or qual data from surveys. I also like Firebase analytics for app performance. I’ve had experience with Looker, but I’ve found Tableau to be more effective in terms of speed of querying the data, ease of using the tool, and analyzing trends in the tool itself.”

The Mom Test: How to talk to customers & learn if your business is a good idea when everyone is lying to you

Posted: Dec 9, 2021 in Book Reviews, Data, Guides, Product Management
Tags: , , , , ,
1

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.

The Devops Handbook: How to Create World-Class Agility, Reliability, & Security in Technology Organizations

Posted: Oct 6, 2021 in Book Reviews, Data, Guides, Product Management
Tags: , , , , , , ,
0

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”

Lean Customer Development

Posted: May 28, 2021 in Book Reviews, Data, Guides, Product Management
Tags: , , ,
2

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

The Lean Startup 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 customers 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.

Actionable Gamification

Posted: May 15, 2021 in Book Reviews, Data, Product Management, Psychology
Tags: , ,
0

Loved this book!

The way Yu-kai Chou has combined the game mechanics and behavioural psychology components to create the Octalysis Gamification Design Framework is remarkable.

The book gives a thorough overview of how you can optimise the below 8 core drivers of Gamification with Human-Focused Design to create engaging and successful experiences in your product, workplace, marketing, and personal lives.

  1. Epic Meaning & Calling
  2. Development & Accomplishment
  3. Empowerment of Creativity & Feedback
  4. Ownership & Possession
  5. Social Influence & Relatedness
  6. Scarcity & Impatience
  7. Unpredictability & Curiosity
  8. Loss & Avoidance

It reminded me of how commonly used gamification mechanics are outside of games, when my RunKeeper app told me that my last run at the weekend was my 34th fastest – a reminder I need to get out more!

The book categorises the 8 core drivers into White Hat and Black Hat techniques and explains the benefit of cultures where people are intrinsically motivated rather than extrinsically.

An enjoyable learning experience and a recommended read.

Hypothesis-Driven Product Development

Posted: May 14, 2021 in Data, Guides, Product Management
Tags: , , , , , , ,
1

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 or Evolution? The Present and Future of Blockchain and Cryptocurrencies

Posted: May 13, 2021 in Book Reviews, Business, Data, Guides
Tags: , , ,
0

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.

MVP and MMP – an Agile Mindset

Posted: May 9, 2021 in Data, Product Management
Tags: , , , , , , , ,
0

Mmp

MVP (Minimum Viable Product) – the minimum amount of features needed to validate the business hypothesis with target customers.

MMP (Minimum Marketable Product) – the minimum amount of additional features on top of MVP which will allow marketing to start growing the product.

Validated learning is one of the five principles of the Lean Startup method and the MVP technique aims to test the business hypothesis. MVP was introduced in 2001 by Frank Robinson but popularised by Eric Ries through his book The Lean Startup.

Since startups tend to work under conditions of extreme uncertainty with limited resources, validating the hypothesis with target customers early in an efficient way using a prototype, wireframes, surveys or marketing material becomes even more important if it is to avoid the scenario of spending months or years building a product which customers don’t need or want (does not have product/market fit).

Achieving product/market fit would involve multiple iterations on the MVP based on target customer feedback, but once the product/market fit is validated it’s time to build the product for real and head towards an MMP by adding features to enable marketing to start growing and scaling the product, with the first set of additional features usually focusing on MarTech and improving the core customer experience.

Now, with an Agile mindset of iterating frequently based on value, it makes the MVP technique similar to Agile product development – building a product that customers need, want and loves by frequently talking to customers/target customers and we only need to look at three of the twelve Agile principles (also introduced in 2001) to see this:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Simplicity–the art of maximizing the amount of work not done–is essential.

Welcome changing requirements. Agile processes harness change for the customer’s competitive advantage.

Because of this, I prefer to use a broader definition of MVP: the minimum amount of effort needed to learn. This is because you can apply the MVP technique (Agile mindset) to a multitude of scenarios outside of launching a new product at a startup where you get the same benefits of reducing wasted money/effort/time by learning sooner rather than later, whether it’s a:

  • New Product – validate before building the whole product
  • New Feature – experiment rapidly before building and rolling out the full feature
  • New Process – being inclusive/gaining feedback before a full roll-out
  • Retrospective – ensure teams are empowered to make changes before having retros
  • Complex Solutions – start discussions early with assumptions before waiting for concrete answers
  • New House – view before purchasing
  • New Job – research/interview before accepting a job
  • New relationship – dating before marriage
  • New Car – test drive before purchase

Start small and fail fast!

Adding a new feature to an existing product is the most common scenario where you can use an MVP approach, but also where it’s most common for businesses to spend months building a new feature that turns out to be low value to customers. Similar to a new product, it’s important to validate new features where the projected value is uncertain by building a lightweight prototype/wireframes to validate with target customers when conducting interviews.

Saying this, if you have qualitative/quantitive data which gives high confidence that solving the problem will be valuable and time to market is important, then it’s equally effective to just develop and go live with the basics you need for the new feature to function at the right quality, then iterate in an Agile way.

When there is uncertainty, break it down, start small, test and learn quickly and it’s surprising how much easier and efficient the problem is to solve.

With tools 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.

Product Roadmaps

Posted: May 8, 2021 in Business, Data, Guides, Product Management
Tags: , , ,
0

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.

Uncharted: How to Map the Future Together

Posted: Apr 11, 2021 in Book Reviews, Business, Data
Tags: ,
0

A thought-provoking read which explains the impossibility of predicting a certain future, but using experiments, working together and staying open-minded results in a more probable future.

Remarkably this book was written just before the Covid-19 pandemic!

Even though futures are impossible to predict, by having shared, passionate guiding principles or an inspiring vision can increase the chances of reaching our goals even with extreme uncertainty, where we only need to look at how art and cathedrals are created as evidence of this.

The book touches on how traditional management is addicted to masterplans and want safety and certainty, not creativity and risk that come with experimentation, which as a result constrains their chance to map a safer future. This section reminded me of Waterfall vs. Lean/Agile.

More automation is a common prediction of the future, but Margaret explains that this comes with a risk of falling into a trap: more need for certainty, more dependency on technology; less skill, more need. The more we depend on machines to think for us the less good we become of thinking for ourselves.

“Making the future is a collective activity…the capacity to see multiple futures depends critically on the widest possible range of contributors and collaborators.”

Should analytics tracking be part of the DoD?

Posted: Oct 11, 2019 in Data, Product Management
Tags: , , , , , ,
0

Analytics

The short answer is yes – the product/team will 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 important to ensure that analytics/tracking is baked into the actual feature acceptance criteria/DoD, is so then:

  1. You can measure the value/outcome which the output had on the customer
  2. It doesn’t get forgotten
  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 up for success.

Using ‘Velocity’ for Product Planning and Optimisation

Posted: Oct 10, 2019 in Data, Product Management
Tags: , , , , , ,
0

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

The Rise of DevOps

Posted: Feb 13, 2019 in Data, Product Management
Tags: , , , , , , , ,
0

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.

Capacity Planning

Posted: Feb 7, 2019 in Business, Data, Product Management, Recruitment
Tags: , , , , , , , ,
0

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.

Feature Pipelines

Posted: Jan 22, 2019 in Data, Guides, Product Management
Tags: , , , , ,
0

Pipeline

With a long list of ideas / problems (features) to solve, there needs to be a solid view of exactly where features are in the idea to customer flow, so that anyone can view the status of a feature anytime without constantly asking.

Having a ‘feature pipeline’ report also proves helpful when providing stakeholder monthly / quarterly product updates.

A feature pipeline typically has multiple columns similar to a Kanban view, but it’s important to keep the content at a high- level (feature / epic) rather than stories.

Pipeline

Example Feature Pipeline Format

Some of the columns you’d have on a Feature Pipeline would be:

  1. ‘Idea’: which would be a long list of features sorted by value
  2. ‘To Be T-Shirt Sized‘ (WIP 5): top 5 highest value features move over to a sizing column – in order for the idea to be prioritised on the product roadmap you need a rough size. It’s recommended to have a WIP (work in progress) limit
  3. ‘Capacity Planning‘: once the feature has been roughly sized, it’s then possible to analyse when the feature can be worked on based on capacity and priority (value vs. effort (t-shirt size))
  4. ‘Delivery Quarter‘: based on the capacity planner which should drive the start and end dates of features on the product roadmap, what quarter does the feature planned to be delivered in

There are plenty of tools available to visualise your feature pipeline eg. Aha! and JIRA and it’s a good idea to compliment that with a guide which includes SLAs for each stage of the pipeline and a t-shirt size mapping, so it’s clear what a ‘Small’ or ‘Large’ is for example.

Having a Feature Pipeline in your product toolkit for everyone to access when they want will help ensure that high priority ideas get to customers in a timely and transparent way.

Setting Delivery Goals

Posted: Jan 15, 2019 in Data, Product Management
Tags: , , , , ,
2

Goals

No matter what product a development team works on, there will often be a big backlog full of high priority customer-centric / commercial work to deliver, technical improvements to make, bug fixing, getting after the next generation technology and security / regulatory / compliance work, so it’s important that there’s clarity over what the specific headline goals are for the development team to achieve over the next sprint / time period.

Some key points when setting goals:

  • They should be specific, but also be accompanied by a high level summary of the bigger picture
  • They should all be action-orientated
  • Make sure your goals are measurable so you know if they’re done or not at the end of the period
  • Indicate a period they’re valid for until they’re reviewed
  • Share the goals with stakeholders and senior management, as well as the review of whether the goals were ‘done’ or ‘moved over to the next period’
  • They should be realistic and the development team should agree to the goals

Setting frequent delivery goals is not only important so that the right focus is being spent on the right things which will increase the likelihood of making progress on solving the highest priority problems, but it also gives visibility of the overall progress made on product iterations and highlights problems in the process if goals are frequently not met, whether it’s due to build pipeline / environment issues or last minute dependencies for example, which should be discussed in the retrospective.

Setting delivery goals, reviewing, celebrating and learning from them should be the norm like it is when everyone’s objectives are set across the wider business.

Gap analysis using ‘As Is’ and ‘To Be’ flows

Posted: Nov 19, 2018 in Data, Guides, Product Management
Tags: , , , , ,
1

Gap analysis

A Product Manager creating and maintaining documentation for new and existing features is just as important as those who maintain documentation in other roles especially developers.

Whether you use Confluence or other documentation software, having documentation makes it easy to provide context and clarity around the importance of getting after a particular feature whether it’s to the development teams or stakeholders.

When a new feature / problem / idea has cropped up, it becomes very useful to start documenting elements before any development effort is spent creating user stories or getting Product Backlog Items (PBIs) in a ‘ready‘ state. The key elements being:

  • One line description about what the feature is
  • Tagging in contacts eg. Product Manager, Technical Architect, Scrum Master, Stakeholders etc
  • Problem / Value including metrics / data
  • High-level requirements
  • ‘As Is‘ and ‘To Be‘ flows which indicates where the gaps are
  • Competitor analysis if relevant
  • Actions / Next Steps
  • Technical details
  • Identifying and Tagging in dependencies

Having ‘As Is’ (Current State) and ‘To Be’ (Desired State) flows is a great way of clearly identifying where the gaps are, where you need to get to, what your competitors are doing in addition and what you need to do to get to your desired state. Having requirements visualised in this way also provides clarity of what you’re looking to achieve and becomes an easy way to digest and collaborate on the requirements vs. a long list of written requirements.

Spending time documenting the analysis of the idea / problem will help get the idea to a customer as efficiently as possible, providing clarity to the stakeholders and developers as to the ‘what‘ and ‘why‘.

A prioritised ‘Feature Backlog’

Posted: Jul 25, 2018 in Business, Data, Product Management
Tags: , , , , , , ,
0

To compliment the Product Roadmap, there should be a prioritised product ‘Feature Backlog’ which gives both stakeholders and the development teams a detailed overview of the Product Roadmap items still at that high level (Epics / Product Iterations).

If you use JIRA to manage your software delivery projects and you have your product roadmap items at an Epic level, then you’re able to simply setup a Kanban board with just one column called ‘Feature Backlog’ with a filter set to show only Epics and Epics which are ‘in progress’ or ‘to do’.

To visualise the feature backlog in a better way than the Kanban board, it’s possible to also show that same JIRA epic search filter across the likes of Confluence or Aha! where you can specify what JIRA fields to show.

Depending on your custom fields in JIRA, looking at the Feature Backlog should give stakeholders and development teams working on the product a high level (iteration / epic) idea of:

  • Priority order of all epics / iterations
  • Status – what’s in progress, planned or to do
  • Business value – whether it’s driving x incremental revenue, saving x money, avoiding x fees, meeting regulatory requirements, contract deadlines, tech debt, advancing technology etc
  • Description of the iteration / problem you’re solving
  • Delivery date which should match the dates on the product roadmap
  • Size of work

The Feature Backlog is a great way of showcasing at a high level the value of the product iterations which are currently being worked on and what’s planned in the next twelve months.

The Feature Backlog also helps the development teams understand the details of what problems are upcoming to solve, so they’re able to think about how to approach each epic / product iteration well in advance.

Recognising and celebrating success 

Posted: Jul 19, 2018 in Business, Data, Product Management, Psychology
Tags: , , ,
0

Celebrate

There are always endless amounts of tasks which need doing or processes to improve, but it’s important to frequently stop to say thanks and well done to the craftsman who have created the magic.

Because of the vast amounts of items on the agenda, unless quality time is spent communicating the high valuable work which has been delivered for the business and customers it’s easy for those pieces of work to get forgotten, but when looking back at those items which did get delivered it would always be something to be proud of and something to celebrate with your fellow colleagues.

A few good ways of saying thanks and showcasing the awesome high value work the development teams have delivered:

  • Product iteration alerts – as soon as an item has been delivered, not only is it essential to let stakeholders know what has just gone live to customers, but it’s equally important to shout out the teams who have been involved in the delivery to say thanks and well done. Using some quotes from key stakeholders is a nice touch also
  • Quarterly delivery reviews – looking forward at the exciting future planned product iterations and new product launches happens frequently, but equally it’s important to take some time to look back at all of the awesome iterations the development teams have delivered over the previous few months
  • Team lunches / nights out – escaping from the office to hit a nice restaurant or bar at the end of a milestone or project delivery
  • Adhoc thanks and well done – after an important launch happens, informally gather up the troops to say thanks and well done for their remarkable achievement re-emphasising what it means for the business and customers

There’s plenty of other ways to recognise and celebrate success, but just making a small amount of effort frequently to recognise the hard work and positive impact the development teams are making will inject pride and drive into the development teams.

Older Entries