Product Vision: UXDX Community 2018 Trend

One of the misconceptions about agile is that you don’t need to plan - you can react and change as you go. However, product planning is just as important in an agile context as in traditional waterfall environments.

In the previous article on Agile Transformation, we discussed the benefit of having a goal and principles for your product. A visible and inspiring goal helps to motivate the team to focus and commit by instilling a sense of purpose into their work. However a good goal describes the outcome you are trying to achieve, which is too high level to provide the necessary direction for a team as they move into implementation.

This is where the product vision comes in. The vision process is where the team take a step back from the details of the product to spend time understanding the problem, ideating on solutions and defining the high level experimentation roadmap for delivery. Unlike the Design phase of a Waterfall process, the Vision process is an ongoing, iterative activity throughout the life of a product.

The aim of UXDX is to help people to implement the new theories that they learn so we ask all of our speakers to demonstrate how to put the theories they advocate into practice. I’ve collated some of the approaches that our UXDX Community speakers have taken to defining their product vision below.

Defining the Problem

In his talk, Val Scholz, Head of Growth at Revolut, highlighted the problem of teams rushing to solutions. His teams spend 70-80% of their time researching the problem space before they start any implementation. This concept was echoed by numerous other speakers. It’s easy to jump to solutions that we think will work but research shows that up to two thirds of product decisions do not help to meet the goals of the product.

“Up to two thirds of product decisions do not help to meet the goals of the product.”

The more time a teams spends understanding the customer and the problem space the more time is saved by avoiding building unnecessary features, enabling the team to focus their energy in the right areas.

Principles, Assumptions and Experiments

The first step in recovery is admitting that you have a problem, and the first step in product development is admitting that you don’t know the answers.

To move forward, in the right direction, start by documenting your assumptions so you, and your team, can start designing experiments around validating these assumptions. This in turn will reduce the risk of building a product that customers don’t want. John Buckley, UX Designer at Frontend.com, gave a talk where he advocated documenting your assumptions in three key areas:

your customers and their needs
the business model behind the product
the technical challenges

John also stressed the importance of maintaining these assumptions and experiments in a centralised and public location (within your organisation) so that the team are constantly being reminded of the remaining gaps in their understanding of the problem space.

With your assumptions clearly defined, the next step isto rank them in order of the highest reward. Deborah Clarke, Director of Product at Cartrawler, gave a talk on prioritising product decisions. Deborah presented a model for ranking experiments that a team should take based on the value of the learning that can be achieved, offset against the risk in pursuing the experiment. Have a look at Deborah’s talk to learn more about a decision that Deborah made around Cartrawler’s move into mobile.

The final piece of preparation is to define the product principles. Product teams always face decisions when creating a product, and often there is not a clear answer to these questions - there are valid arguments for and against each option. This is where a team benefits from having clear guiding principles. In John’s talk he gave an entertaining overview of the best practices around product principle definition, including some evocative examples of good design principles and their power. The one that stuck with me the most is the UK Government’s design principle of “This is for everyone”. When product teams are faced with a challenging new feature they know from their guiding principle that accessibility should win out over functionality. This kind of clarity speeds up decision making and ensures alignment within the team.

Research

As expected a number of trends emerged from the talks across the 8 cities around the best practices in user research. We will go into more detail on user research approaches in the next article on Implementation but the focus during the vision process is on the high level research that teams can do to validate the product direction.

The most popular approach was definitely Jake Knapp’s Design Sprint. Timothy Allison, Product Design Lead at Zendesk, and Nick Gill, UX Researcher at Flyt, who covered the Design Sprint process in the most detail. If you haven’t heard about Design Sprints before the core concept is to get the full product team, including senior stakeholders, together for a week and do targeted research, analysis and prototyping to validate the core assumptions of your product. The timeboxed nature of the process, along with the structure for each day helps teams to really accelerate their discovery process.

The Jobs to be Done framework was another popular framework that came up during the conference series. I touched on the success that I’ve found in running Jobs to be Done workshops in Aer Lingus during my talk on implementing change in organisations.

Jobs to be Done helps companies to shift their mindset from being product focused, to being more customer centric. Instead of asking “how can I make this product better?” teams ask themselves, and their customers, “what is the job that my customer is trying to achieve?”, and “how can I improve that for them - speed, price, quality, ease etc.?” The concept is that while you may be selling a product, for example a drill, your customer isn’t buying that product - they are buy a tool to solve their problem: they need a hole in their wall. The process is a bit more complicated than I’ve outlined above but this simple shift in thinking is critical for teams looking to move away from feature based product development to outcome based development.

While both frameworks above are great for providing structure to your research a frequent challenge that people encounter is when to rely more on customer research and when should they use the innovation within the team. This was addressed by Raquel Damas, UX Lead at Shopify Plus, in her fantastic talk on UX Research. Raquel’s advice is to align your approach with the type of product or feature that you are proposing. If the focus is on incremental improvement then the research needs to center around existing customers and their needs. However if you are pushing a more innovative product then the team needs to be more proactive in the product direction. The difference in approach that you need to take should be clear from the assumption you are trying to validate. Using Raquels advice you can define the most effective experiment for validating your assumption.

Product Roadmap

Having spent the time understanding the problem space and running a number of research experiments to validate your assumptions you should now be in a good position to start defining the solution for the problem(s) that your customers are facing. This is where most teams move towards the Minimum Viable Product. Unfortunately this term has become overused and misunderstood which has led to poor implementation approaches. These challenges were the next set of trends that the UXDX Community talks addressed.

Shared Understanding of the Problem

In an ideal situation your development team would have been involved during the Problem definition stage however this is often conducted separately by the product team. A common mistake that many teams make is that they move from vision to implementation without bringing the full product team up to speed on all of the work that has been completed. The reason why this is so important is that the development team will make technical decisions throughout the development phase. These decisions are based on good intentions but if they make some invalid assumptions about the customers or the problem space then this will lead to problems and delays later in the development cycle.

In his talk, Will Demaine, Engineer at Fat Lama, extols the virtues of having a clear roadmap for your product. Will recounted a story about when he was working on the Uber for Business product at Uber. They wanted to move quickly, so they decided to jump in and build the simplest product that would meet the high-level needs of their customers. And this approach was successful; they built a product that was perfect for small businesses. The problem arose shortly afterwards though, when the sales department wanted to start selling the product to larger businesses. During development the team had made a conscious decision to leave out the ability to bundle employees into groups (e.g. office locations, departments etc.) as it would have added time and complexity to the original delivery. This feature was critical to larger companies though as they could not manage one account with tens or hundreds of thousands of people. The team were right that groups would add complexity to the product, but that complexity rose significantly as soon as the product went live because now they had to change the architecture of the product while supporting all of the existing customers. The initial time that was saved in the first product rollout quickly disappeared as it took more than 2 years to build the groups functionality into the product.

Jan Tryggvason, Product Owner at Nordnet Bank, touched on the same concept in his talk on How to Figure out what to Build First. Mapping out the end to end product offering is a crucial prerequisite for deciding on the initial product offering.

While it may sound like Will and Jan are advocating for a return to big waterfall design and delivery approaches this isn’t the case. The team need to work together on defining the right level of detail here to make sure that they don’t fall into the “big design” trap because the product will change based on initial user feedback. Unfortunately there is no exact answer here, the team need to decide that they have enough information to reduce unnecessary pain later in the product delivery life-cycle. By sharing the research into the problem space the team will understand the long term vision and this will help them to make the best decision for the particular issue at hand.

Minimise

Juan Munoz, Senior Software Engineer at Pleo, gave a talk on Minimum Lovable Product where he argued that you need to focus on making your product lovable in order to get the traction in the early days. MVP’s can’t solve all of your customer’s problems so you need to focus on doing one thing amazingly: identify your users biggest pain points and solve one of those. Otherwise your product will struggle to get through the noise of all of the other tools that only half solve the problem. One amazing feature is better than 100 mediocre features.

Experiment to Validate

Finally, but of critical importance, there will be disagreements about what constitutes lovable and what features should make it into your MLP (Minimum Lovable Product). As Anna Sitnikova, Product Manager at iZettle, explains, consensus takes too long and involves too much whiteboarding. What is required are simple experiments that will test the assumptions a team has made for why particular features will solve the problem that the team is working on. These experiments arm the team with solid data that they can use to justify their product choices and argue their position effectively when presented with HIPPO’s or the latest industry trends.

The most effective example of this approach I’ve come across is from Segment. Segment are a B2B data integration platform that have raised over $120m in funding but things weren’t always so rosy. They were nearly out of runway and were very close to shutting down just a few short years ago. One of the founders believed that the company should pivot to being a data integrator using some technology they had created to support their previous business idea. The CEO, Peter Reinhardt wasn’t convinced, but they proposed an experiment to test the idea. Peter was confident the idea would fail but the experiment was quick and easy, the potential value was large and it demonstrated to the team that their ideas were being listened to. Given I introduced Segment as a data integrator I think you can figure out how the experiment went. Peter describes the response as the real feeling of product-market fit.

Until you find product market fit you keep thinking you have found it. But when you actually find it there is no mistaking it.

While there is research that shows that up to two thirds of product ideas are wrong, this example exposes a potentially even bigger problem - there are many fantastic ideas that never seen the light of day because teams are too busy building the wrong ideas. If Peter had shot down the idea then Segment would probably have died instead of approaching unicorn status.

Communicating

Having defined your product vision the worst thing you can do it keep it to yourself. Communication ensures alignment within and around your team for your product and helps to deliver the autonomy that enables high performing teams. In Yaroslav Karulin’s talk about Product Team Management he described the three levels of Product Vision communication.

The first level of communication: within the team.

The team need to be intimately aware of the product assumptions, goals and upcoming experiments to validate the assumptions and meet the goals.

The second level of communication: across the delivery organisation.

Depending on the size of your company there could be dozens or more teams working on the suite of products that your company provides. For consistency, as well as ensuring that teams are not working against each other, communication across the organisation is key.

In traditional organisations communication can be difficult but the departmental structures usually protect against competing teams. In Revolut they use a “bacteria style” approach for team management; teams aren’t dedicated to a particular area, they can pitch any idea and when a team gets too large it splits in two. This ensures that the teams stay nimble but it introduces complexity around coordination. To manage the risk each team has to publicly publish their weekly plans and the team leads are responsible for identifying and resolving any potential conflicts.

The third level of communication: with management.

Management communication is key for two reasons; trust and feedback. Managing by features gives management a sense of control that is removed when they move to managing by outcome. This approach requires a lot of trust from management in the competence and insightfulness of the delivery team. OKR’s (Objectives and Key Results) are being used by a number of teams to help build this trust. The regular reporting on progress against their key outcomes enables management to deliver great autonomy to the teams.

In terms of feedback, while HIPPO is considered a negative term it must be remembered that the management team are aligned closer with the company direction and are in regular contact with customers so they are more informed in a number of areas, and critically, they know what their customers will pay for. While we need to avoid HIPPO feature specification we need to take these insights seriously and design experiments around validating them.

From Vision to Execution

So having spent the time understanding the problem, designing your experiments and mapping out your high level product roadmap it’s now time to start implementation.

In the next article in our series we will share the latest trends that teams are using to execute on their vision, covering the full UXDX Model of activities across UX and Development.

UXDX Community

UXDX has a mission to help teams accelerate product success. We believe that this is done by incorporating UX into the product lifecycle and breaking down the silos within teams. Throughout May and June 2018 UXDX ran community events in 8 different cities across Europe. The core concept was the same; bring together different speakers, from UXers, designers, product managers and developers, to give insights across the whole product life-cycle. This series of blogs will go through the trends uncovered during the events.