A note for new subscribers: This post is part of a series on my notes on technology product management (this is what I do for a living). You might notice that these posts often link to older posts in the series on LinkedIn even though they are all available on this blog. That is intended for folks who only want to follow future product management related posts. Finally, for all those of you who don’t build tech products for a living, I believe many of these notes have broader applicability. And I hope you find that to be the case as well…
——————————————————————————————————-
A quick overview of what we’ve covered on “Notes on Product Management” so far –
- Overall: The IC PM Role, The 4 key skills, Remote + Pandemic PM, 5 Decision Making frameworks/heuristics, Problem finding/solving with executives, Managing psychology
- Skill #1 – Problem finding: Most important skill, Problem statement and hypothesis, Building Strategy, Validating problem statements and hypotheses, Exploration OKRs
- Skill #2 – Selling: Sales and Marketing, Writing for executive audiences, Product executive relationships, Learning to sell
- Skill #3 – Problem Solving: Roadmap, Product specs, Solving for Usability, Solving for Feasibility, PM<>Eng collaboration, Ramps and launch checklist, Design visions (today’s post)
- Skill #4 – Building effective teams: Knowing thyself, Your manager, Product team culture, 5 habits – high velocity product teams, Effective 1:1s, Kick Offs, Effective team meetings
- Managing your career: Getting in – I, Getting in – II
——————————————————————————————————-
A design vision is a powerful tool. The ability to create one cuts across 2 out of our 4 core skills. They are primarily a “problem solving” tool as they help transform our ideas for a solution to visuals. But they are also key to our ability to sell/influence others.
The design vision brings our strategy document to life. It is critical – so much so that it is best to not ship a strategy doc without a link to the vision video that illustrates our roadmap.
A science-first approach to understanding design
Before getting into the details of the approach, I wanted to share some background on my journey. I had no training in anything related to design when I became a PM. I am not one of those people who naturally gravitated to art or design either. I knew I had decent (read: passable) aesthetic sense. But that was it. So, for the first eighteen months in my journey as a PM, I leaned heavily on my design partners and other PMs who seemed to know what they were doing.
But this part of being a PM gave me the “heebiejeebies.” Every time I was presented with a screen, I felt like an imposter who was going to be outed for not knowing how to do my job.
I then moved to working on consumer products, got lucky to get the opportunity to get schooled by a couple of product and design leaders who – through osmosis – helped me understand how to deconstruct a screen and what to look for. The approach I’ve developed since is an approach that emphasizes the science over the art – i.e., I take a very considered step-by-step approach.
What I do know is that once you apply the science hundreds of times, you get glimpses of the art of looking at a screen and experiencing that niggling feeling in the gut that tells you something is wrong. Or when you are midway through the process of creating a design vision and just know it isn’t developing as it should be. Understanding the science has helped me get in touch with and appreciate the art.
With that said, let’s dig in.
The 4 steps of the process
(i) Create an exploration OKR with an expectation for one of two kinds of design visions.
Both parts of this step are equally important.
First, allocate sufficient time during the quarter to create a design vision – both on your calendar as well as your design partner’s calendar. Don’t expect your design partner to just cook something up in their spare time. That doesn’t work. Creating a design vision is a true exercise in partnership and needs dedicate time – ideally in sync with the creation of your strategy.
Second, there are two kinds of design visions. I differentiate them by their horizons:
Variant 1 – 12-18 month horizon: The primary purpose of this variant is to inspire. It needs lower fidelity designs (i.e., you don’t need to sweat the exact user interface or copy) and is useful when you’re charting the path forward for a large and ambiguous problem.
Variant 2 – 6-9 month horizon: The primary purpose of this variant is to get the broader team excited about the product we’ll ship in the next 2-3 quarters. In this case, you need reasonably high fidelity (UI that is 80% complete, illustrative copy). This is more focused in scope.
It helps to align on the variant as you define the exploration OKR
(ii) Kick off by aligning on value and creating a clear (and reasonable) timeline.
The next step is to kick off (see this post on kick offs) – this is especially important on a new product team. If the team is not new, it helps to do a light version of this. The key steps are:
(a) Make sure everyone is aligned on the problem we’re solving and the value of the solution we want to build. This is where design visions can go sideways. Good problem statements help define what is not in scope and keep the group focused.
(b) Create a clear and reasonable timeline for 2 phases:
- Diverge: During this phase – it can be done in 2-3 weeks – the design team should have plenty of space to brainstorm/organize brainstorms, gather inputs, and put a storyboard together. It is good to plan small group check ins once a week during this phase.
- Converge: This phase – typically ~2x longer than the diverge phase – is when you begin iterating closely and rev-ing based on feedback. During this time, I’d recommend setting time very often – at minimum thrice per week and a check in with the broader team once a week. It isn’t uncommon to check in via a daily standup during this phase. If this sounds like an intense phase, it is. :-) But it is also among the most fun and memorable phases when you’re in the trenches with your design partner.
Note on timeline: Every once in a while, you will sprint and create a design vision in 2 weeks because of some external/executive pressure. While exhilarating if done well, it is definitely not a sustainable way to create these. I’d suggest reserving that energy for extenuating circumstances.
(iii) Learn to facilitate useful discussions by focusing on one aspect of the User Experience equation at a time
The best thing you can do as a product partner is to facilitate structured discussion. For example, it is tempting to just jump into providing random feedback on the colors and user interface. But that will just result in unproductive discussions and lost time.
The basis for structured discussion on designs flows from an equation I shared before for the user experience:
Let’s break out the components:
- User interface (UI) = Layouts, fonts, colors, illustrations, and copy.
- Interaction design (IxD) = Effects of clicks, taps, and gestures – if you are building a feature as part of a larger product, the interaction design will be dictated by the design system in the product
- Information architecture (IA) = How the entire app/website is organized – if you are building within a large app or website, your product/feature is just one part of the entire user experience. So, every other feature and product plays a part in the user’s experience.
- Value = Both real and perceived value – real value is tangible and perceived value is often a result of the story/narrative/marketing. Both matter. Also, value is multiplied. This means if the value is 0, it negates any work on the rest of the user experience.
I laid out the equation in this way because our natural instincts when looking at designs move from right to left.
But much of life is acting in ways that are opposite to some of our natural instincts. And giving useful feedback works similarly. So, the equation should instead be written the other way around.
This means you spend a few days or week at a time working through each of these components in order:
(1) Value: This is what you did in the kick-off. You’ll need to spend as much time as necessary to get clear on the problem you’re solving and the intended value of your solution to the user.
(2) Information Architecture (IA): The IA should be the first stop as it requires us to make foundational decisions about how the user interacts with our product/feature as part of their overall user experience on our app. This involves working on questions like – how will the user discover our feature?, what are the key components on the screen?, what are the primary and secondary tap targets?
IA questions are the toughest questions to answer in my experience. It is worth taking the time to get this stage right.
(3) Interaction Design (ID): The next step is to consider the interactions in detail. This involves understanding the impact of clicks or taps or gestures, experimenting with motion design, etc. This part of the experience dictates how the page responds to a user.
In my experience, this is typically dictated by the design system as you generally want to be consistent with the rest of the experience. If you are working on a smaller app/site and don’t have a design system, it is a great prompt to create one.
(4) User interface (UI): This tends to be the other area to spend a lot of time on. Again, fonts, colors, and illustration tend to be heavily design system dependent. But there’s tremendous opportunity to shape (i) layouts and (ii) copy.
(i) The function of a good layout is to establish hierarchy in the eyes of the user. It should be easy to understand what to pay attention to and what to do next. This is one of those things you learn by experimenting yourself and observing good hierarchy in other products that you use. Simpler is better. And that is easier said than done.
(ii) Simple/clear instructional copy can have massive impact on your user experience. Copy could be the subject of an entire post or even a series of posts. So, I’m undoubtedly not going to do it justice in two paragraphs. That caveat aside, I’ve learnt two lessons about copy. First, partner closely with folks who are good at creating copy – lean on any copywriters in the organization along with your product marketing counterparts. Creating good copy is a team sport.
Second, invest in learning about using good copy – e.g., check out sites like this. The right subject line on an email, the right page header, and the right CTA text can drive significant lifts in your key metrics. It is worth investing your time in getting those words right.
(iv) Bring it all together with a video
There are two simple steps here:
(a) Use a simple storytelling slide template. Here’s an example.
(b) Record a video with narration and background music. Video helps for 3 reasons:
- It avoids any presentation hiccups when you share out your design vision. Computers have a way of acting up and becoming slow just before key presentations.
- Uplifting music adds a LOT to the final presentation
- The video file is easily shareable. That’s the outcome you want. :-)
——————————————————————————————————-
As you can tell, this post is as much about creating a design vision as it is about becoming a better partner to the design team. If I had to pick the highest impact habit out of all of this, it is learning to facilitate focused discussion on a screen.
It is not just useful because it provides focus to the team (it does that). It is useful because it helps us hone our own skills. Every time we end up pausing and focusing on the IA/information architecture and discussing it in detail, we’ll learn from everyone else in the room. The same happens as we debate layout and copy.
And once we habitually approach design conversations with this sort of structure, it has an unintended side-effect. As the scientific approach provides a baseline amount of rigor, it then frees everyone in the room to appreciate and participate in the art of building a good product.
When that happens and when it comes together in a powerful design vision video that gets the team excited and inspired, it is magical.
A Learning a Day 