Joshua Long
March 22, 2022

Part ll: Designing with a plan

But honestly, how do you, as a designer, push for product design to be grounded in reality (market dynamics and development feasibility)? Product managers often come in with their perspective on what to build - sometimes it's a set of evaluation standards, sometimes it's pure gut, and sometimes it's an extensive set of things that are compromises from clients and internal stakeholders.

But honestly, how do you, as a designer, push for product design to be grounded in reality (market dynamics and development feasibility)? Product managers often come in with their perspective on what to build - sometimes it's a set of evaluation standards, sometimes it's pure gut, and sometimes it's an extensive set of things that are compromises from clients and internal stakeholders.

In a typical "best case" scenario, PMs use RICE or some RICE iteration - weighted scoring or Value vs. LOE. The problem is, it's confusing when they try to explain it - or even if you're in the room while they are running a prioritization session, you can't remember, let alone begin to explain how things got prioritized after you walk out. Perhaps most confusingly, it's not the same framework quarter-to-quarter or even week-to-week. How things get prioritized for the roadmap always seems different, not repeatable, and not tied to clear, contextualized user needs.  

So what is a good designer to do?

First, to prioritize effectively, it's essential to think about what you're designing and building with your team as a 'thing' that helps a real person achieve some outcome. We're not building a form to login, with slides for an onboarding flow, an input for a search to query a database, etc. We're helping people understand if their educator skills can translate in the tech world or automate tracking of goods along their supply chain.

Yes, you have to design and build the individual features, but they now become steps to unlock a specific outcome for a user. We all know that designers can be more effective by simply thinking about and reframing, and grouping features into user activities and outcomes. We can then iterate and design with a perspective that truly starts with a person who can and hopefully will use this solution to achieve their desired outcome.

But, not so fast. Before we jump into Figma, let's think about whether all those activities are the right ones to focus on! Roadmap planning often starts with WAY too many user outcomes to be coherently designed and developed in one quarter.

Often, how PMs approach deciding what is in and what is out starts within strategies distilled from books, workshops, videos - makes its way into spreadsheets - and then makes its way back out into slides. This book to the spreadsheet to slide process often leaves design and, frankly, most stakeholders unsure of - and unable to explain - why they are prioritizing the things they are building with any sense of coherence.

To control this spin of uncertainty, you can encourage the team to pull back and look at the activities and evaluate them consistently - ideally starting with market context.

For example, when you're thinking about each activity - are users even achieving this outcome today? Do you see a single solution that many of your users or target users are already using, and you need to flip them off with a better UX?

Or can a user solve this need by mixing and matching a few solutions together, but the experience is fragmented? Maybe they want to achieve this outcome so profoundly that they are willing to create their own hacked solution - using spreadsheets, iPhones, and manual processes - leaving the sky as the limit for designing a product to get them to their desired outcome better.

Knowing your competitive landscape at this level is critical for effective prioritization and knowing what you are designing to do - flip users, streamline the experience, or wow with a new solution. You might disqualify some of these outcomes and not even design for them if you see that a big enough competitor or group of competitors are already focused on the space. On the other hand, If you're finding people trying to solve this problem by themselves with hacks, the team can rally confidently around a wide-open opportunity to give users a new and better solution with your product.

Now let's talk about a question all good design starts with but maybe doesn't answer in a broad enough context - how many real people do you think will try to accomplish this outcome with your solution? Do you have any leads that confirm demand for this? Do you have research to support the need for what you're trying to build? Even a gut check on this is a vital step - i.e., not many people, a specific set of people, half your users, more than half your users, pretty much everyone you've ever talked to. Here you might find that you've grouped many features that don't solve a real need for that many people - in that case, it may not be worth designing or building these things.

A final critical question is how hard is it for your company to build this set of features? Of course, the WHAT should drive the HOW, but a plan that can't be executed is useless. It's essential to zoom back in to be realistic about meeting user outcomes WITH the atomic unit (features) of what you're building and how long it will take. Days, weeks, months? How many?

Considering all of these things together is how you can properly prioritize and sequence a design and development plan for a team that gives team confidence, focus, and meaning.

A prioritization approach that takes real inputs and gives you a framework to think and create. Now that you have the framing, you have a place that you can create with confidence. When you harness your energy in a clear direction, collaborating with a team with a shared understanding of WHY you can build a design foundation that you are confident in - and ready for the next bigger and more audacious goal that comes to you.

Simply starting with a design sprint or being asked to "just get started" with a scattered shot understanding of business/user goals and feasibility is flawed and will ultimately waste time and money. It's most important to be aligned and confident in what you're building before you design and build it - with a foundation of market dynamics, user needs, and execution feasibility to guide design and development.

If you haven't already, read:

Part l: Designing without a Plan