Product design: building a product with understanding — part 1

The stress of scope, timeline, and uncertainty can make us focus more on controlling things by counting features and user stories, so we sort of lose focus on how we actually apply the design mindset and product development process. This prompts us to constantly raise awareness about what would help us keep the focus on good final delivery.

Inspired by the current project we are working on and building it from scratch, I pulled out some of the insights that seemed meaningful to me for understanding if we are making good progress with the product — both from the mindset and process standpoint, since both need to come into play for the project to be successful.

It seems to me that it largely comes down to a project team’s understanding of:

• Product design mindset
• Core problem
• The scope
• Prediscovery sprint
• Practicing double diamond
• UX research
• Design collaboration
• The project team shared understanding

In this blog, we will go through the first 4 factors — those 4 are pre-discovery factors out of agile sprints, and the basis for a good start of a project.

Product design mindset

We are currently working on an online streaming platform for sports competitions. As platforms like this currently don’t exist, we need to work really smart and use the design process to feed ourselves with good information on:

• problems revolving around having different user types
• translating live competitions onto a digital environment
• technology options for heavy streaming
• integrate tech into design ideas we might have

This means we need to implement a lot of the design mindset in researching and drafting ideas, and the whole project team needs to have a common baseline knowledge of the high-level product design process. If the whole project team participates in discussing how we are solving real problems for real people, everyone gets to understand the idea of an MVP and we are aligned on the same end goal.

The baseline is to understand who are we helping with this product and how will this product help that person to feel good after using it. To get a clear understanding, we need a reason that is built from research — this means that we’re working to understand the full picture and learn about the details as we move through the project by understanding the users better.

Those details fill in the gaps and build a deep understanding of the product you are building.

For example, for this sports project we are working on, the tricky part was having an idea of how will we gather this understanding without rushing into a bad decision or snoozing or over-engineering the decisions out of fear (for this, I think we have a blind spot far more often than we think). Those two aspects can get the best of you when you don’t understand the full picture as a team.

Core problems

Core problems are those problems that are the biggest and the most wicked ones we need to solve. To explain the “wicked problem”, we can look at the simple Wikipedia definition — it is a problem that is difficult or impossible to solve because of incomplete, contradictory and changing requirements that are often difficult to recognize. Sounds familiar?

If we can recognize them well, we can be fairly certain that we are investing in a product that users will feel good about while using it. Workshops are a good way to dig into that problem since they are one of not so many opportunities where we get to go over business and users’ problems with the stakeholders and the product team all at the same place.

To feel confident about having the right focus during the workshop, it is important to define what we’d like to understand more in order to get a better picture of a core problem. This enables us to focus on the good outcomes — we can use and create user journeys and personas, but if the outcome is that no one really understands how the product needs to work and what problem are we solving, we will probably have a hard time further on.

Our workshop squad on the project I’m talking about included a Design Lead, a Product Designer, a Product Manager and a Tech Lead — all working two days with the client to produce meaningful core ideas and knowledge about the product. In our case, this revolved around understanding:

• the sport itself
• how the live competition works
• multiple roles that are either managing, supervising, judging or competing at the same time
• tight competition logistics
• heavy streaming technology

If we define outcomes as a baseline understanding of these core problems, we can focus on what would help us to get a better sense of the problem scope, and then use personas, user stories and user journeys to describe the insights that are derived from a shared understanding. As a result, we can create the first impression of an MVP version and a full-blown experience version together with the client.

The scope

As we learn about the product, some changes in the scope can happen — this should not surprise us since we didn’t know what we are building before, and now we know it much better. We need those changes to be clear to the whole team and supported by a lot of reasoning behind them. We don’t want to be the guys that just take the information without questioning it — this leads to diverging in how we understand the problem, which is bad for the good outcomes.

In our project, our first impression of user stories that were needed for the MVP had a lot more features and different prioritization. As we learned more about the product, we started getting more reasoning and cut some of the features without the fear that we’ll lose important aspects. For example, it is more clear to us now that we need to focus on the interaction between athletes and referees (and see if this works at all) to be able to plan the scheduling (which won’t be necessary if the core interaction fails).

This should and will happen as we work more, but the knowledge about whether we have good user stories prioritized for the MVP will come only after we deliver the first version — until then, this is our lucky guess.

We have some ideas that we started with, but as we are learning about the details of our users, business and technology, we evolve those ideas and change priorities to make a better fit for the MVP.

If we as a team stay aligned with how we learn about the product, we are investing in understanding. It helps us not get eaten by documentation and makes pivoting situations easier and a lot less dangerous. If the communication is done properly, updating the documentation will come as a natural consequence afterward, but you will have the team that understands the “why” to regroup accordingly — regardless of the phase of the project, you can stay aligned with the overall strategy.

Prediscovery sprint

To make sure that we start developing a good product, a larger portion of discovery before making a lot of ideas is important. This “what am I looking at” sprint is dedicated to divergent thinking and collecting insights. We need to deeply understand the problem we are dealing with before we jump to creating solutions (which also need their portion of discovery once you get to that stage).

Discovery sprints are great ways to collect insights that we will need in order to feed the regular agile sprints, but they are also an important dedicated time for drafting early and drafting fast.

Even though we don’t have all the information needed for design, fast drafting is important to even start thinking about what that information would be. It works well for our team to put draft design thoughts out there, and share it with a fellow designer or a product owner. By doing this, our assumptions start evolving into much more elaborate ones.

Drafting provokes our brain to start producing questions early on, so even if the first drafts are completely off the UX design we think we want, that’s ok, their purpose is to challenge our brain to rethink the problem without promises.

On the project we’re working on, we were:

• defining user stories
• planning on how to jump into this
• framing flows we already framed
• wireframing the screens from a different role’s view
• looking for overlapping between roles
• chunking the stories into meaningful sprints
• estimating the amount of discovery and delivery for each sprint

We did all of this with the intention to be open to changes and to learn more about the product. It is the way that enables us to see the possible tricky situations moving forward, and it is a starting point for collaboration — we had something to look at and practice the critical mindset.

It is meaningful to see how others solved the same or similar problem. But be careful — don’t just blindly copy what you see in other products, because you don’t know whether it works for them, and even if it does, you don’t know if it will work for you. Your best action is to focus on visual understanding and being open to different approaches — this is the diverging phase and it is helpful and necessary to give benchmarks a proper look.

The ideas you will start getting as you collect examples will later run in the back of your head without you noticing and feed your thinking when/if needed.

To sum it all up

Here are a few key takeaways:

• as a team, we need to push the need for understanding of who we are building the product for as much as we can
• we need to be real about where we stand with the current understanding of the problems and research the depths to get to the core problems we need to solve
• once we know the core problems, we can deal with the scope and work our way to the idea of the MVP
• as we work on the product, we need to get familiar with who are the people we are building for and how will our product solve their real problems

We need to remember to practice what we preach and work as a team. To give you a sense of how this all translated to developing a product, read more in the part two of this blog. It covers the “hard production” side and good practices.

If you want to dig deeper into some of these thoughts, here are some great sources that can be a good starting point:

• The Secrets of Creating Great Design Workshops
• A Three-Step Framework For Solving Problems
• Listening Deeply (but also everything else from Indi Young)
• Top 5 takeaways from User Story Mapping (as an intro to Jeff Patton take on user story mapping, but dig deeper)