Rethink Product Delivery

Product Development is Broken


of features fail to deliver value

Microsoft started tracking every feature and discovered that only 33% of good ideas actually delivered the expected value


of people have their hands tied

The delivery team know what is best but they are blocked by company structure and policies from doing the right thing.


more time spent on rework

Teams that use legacy development practices spend more time on rework which kills motivation and slows delivery.

The differences between Projects and Products

Definition of Success

Project: Predictability

Adherence to Time and Cost estimates based on detailed requirements and detailed solution designs completed at the start of the project.

Requires strict process to control scope / assumptions. Scope changes, regardless of importance, are to be minimised.

Product: Outcomes delivered

Value delivered to the business. Recognises that nobody can know all the answers upfront when building a product so scope needs to be flexible in order to deliver the best results.

Requires alignment on the organisational goals, the product goals and the process goals to enable change throughout delivery.


Project: High utilisation of people

People are only temporarily on projects. Different functions are required at different stages in the project so the key is certainty of scope at each stage boundary.

Requires larger batch sizes so that people are on projects for longer to minimise movement of people between projects / downtime.

Product: Low Lead Time for Changes

The delivery efficiency of the team as a whole is more important than individual utilisation. Counter-intuitively this can mean lower utilisation for individuals - people need slack to handle unexpected work.

Requires small batch sizes so that lead time can be minimised. Low batch sizes call for a reduction in handovers so team needs to be more cross functional over time.


Project: Temporary

People assigned by functions temporarily to projects until scope is delivered.

Requires consistent processes across all projects so that people can move between projects with minimal impact.

Product: Long Lived

Dedicated cross-functional people working together as a team throughout the life of the product.

Requires deep specialisation knowledge and bespoke processes that suit the needs of the team.


Project: Scope Based

Funding is tied to the scope of the project. Scope justification is based on expected benefits.

Requires an ability to report on the benefits realised.

Product: Team Based

Funding is calculated based on the size for the team. Team justification is based on expected benefits.

Requires an ability to report continuously on benefits realised.


Project: Organisation is Responsible

Change projects run to roll changes out across an organisation. Managed by central change program and prioritisation at an executive level.

Requires reporting and prioritisation process for changes.

Change happens to people.

Product: Teams are Responsible

Team own and are responsible for process and code, continual optimisation is part of the way the team works.

Requires autonomy to make changes within the team.

People change.

How does it work?

The biggest risk with transitioning from projects to product is to keep treating the team in the same way; feeding them a list of features to develop. This limits alignment, wastes the talent within the team and creates a culture of avoidance of accountability for outcomes - "I did what I was told". Instead, teams need to be assigned particular outcomes that they should achieve, driven by the business priorities.


Data => Insight

Teams should collate quantitative and qualitative data from as many sources as possible - usage analytics, customer interviews, customer services requests, social comments, surveys, etc. But data shouldn't drive decisions - it should inform them. In order to inform effectively you need to group the data into themes and to pull the insights about your customers and their needs out of the data. 

To learn more check out the "Continuous Research" sessions on the agenda


Insight => Hypothesis

Not every problem is worth solving. Teams need to map the identified customer problems to product features that will impact the team's business objectives. But don't stop on the first feature that you think of. Teams should identify as many solutions as possible, with input from all team members, because the first idea is often not the best and different viewpoints deliver better ideas. 

Any mapping from a problem to a solution though is just an assumption - you hypothesise that a feature will solve a customers' problem. The key is making these assumptions explicit because you need to be able to reassess your ideas as new information about your customers is uncovered with each release. 

To learn more check out the "Integrating UX and DX" sessions on the agenda


Hypothesis => Solution

Before you start working on the solution, break your chosen hypothesis down to the key assumptions that underpin the feature solving the customer's problem. Is there a way to incrementally validate these assumptions, starting with the desirability of the solution (a signup form for a new feature), and increasing the fidelity of the prototype to validate the usability and expected behaviours. If the hypothesis doesn't work as expected thank it for saving you time and then throw it in the bin.

To learn more check out the "Integrating UX and DX" sessions on the agenda


Solution to Product

After a prototype has been verified as effective the team need to break down the delivery of the prototype into stages aligned to increasing levels of solving the customer problem. Each stage needs to follow a streamlined delivery process because speed is critical to prevent the research and prototype validation becoming stale. This iterative approach lets teams validate, at scale, that the solution is effective. If the team learn something new they can pivot without having invested too much time. The challenge for building is that this requires flexibility in architecture and design.

To learn more check out the "Architecting for Change" sessions on the agenda


Product to Data

Create a continuous delivery / deployment pipeline to go from code to production with minimal manual effort. Once the product is live the fun is just beginning. Monitor the system and user behaviour to validate that the product is meeting its goals. Using this data and the insights that you learn about your customers you are ready to restart the cycle.

To learn more check out the "Continuous Delivery" sessions on the agenda

Join Us In Dublin and Learn the UXDX Model

Experience 2 days of 60+ inspirational talks and hands-on sessions by world-known product leaders.

Get a Taste of What We Do

    Register for our 50% Pre-Sale on 29th May

    We will be releasing a limited sale of tickets on 29th May for €495 each. Even though the tickets are half price they still include full access to UXDX 2020 including the two days of talks and workshops as well as the networking events around Dublin. Register for the Pre-Sale today.