Product Management: Whys and Hows

Hello world. I don’t usually write real blog posts. But, I’ve been doing quite a bit of thinking about goal setting, alignment, and product management lately, and ended up drafting the following rant on how I approach aligning day to day work with a big, overarching goal.

Apologies that the original audience wasn’t intended to be you, so not everything is artfully dissected and explained. Just a little something I’m pondering and thought could inspire some thinking on setting goals and ensuring that they a) make sense and b) inform day to day decision-making and prioritization.

Whys and hows

An easy litmus test for understanding whether or not our work is aligned with our primary goal, [redacted company/team goal – insert your own BHAG, because jargon], is something I call the How-Why framework. Jazzy, I know.

Starting with the big goal, ask yourself “how” you’ll get there. This should lead to down a couple possible roads. This is good. Choose one road, and ask “how” you’ll get to that point. Going through several “how’s” will get you in the habit of backward planning from a clear and measurable big goal. When starting with the big goal, we ask “how” we’re going to get there to flesh out possible roadmaps.

Here’s an example of a rigorous process I go through daily. Let’s say that I have the problem that I’m hungry, and my goal is to get full as soon as possible. How will I get there? I should eat. How will I get there? I should acquire food. How do I get food? I could open a cabinet and grab something ready-to-eat that I already have at hand; I could prepare something with ingredients I already have; I could have groceries delivered to satisfy either of the first 2 options; I could go to the grocery store to satisfy either of the first 2 options; I could order pre-made food to have it delivered; I could order pre-packaged food and prepare it myself; I could forage and hunt throughout my suburban neighborhood. Woof. That’s a lot of ways to get where I want to be – eventually. But, my goal is to get full, not to craft a masterpiece of culinary delight. Knowing that, I can weigh my options, find the most straight-forward path to achieving my goal, and prioritize options depending on whether or not I need a fallback or whether requirements change during the process.

Most importantly, asking “how” forces us to think about various approaches and to compare their utility in accomplishing our goals.

On the flip-side, when in the trenches working on projects that we’ve carved out, we ask, or perhaps most often answer, “why?”. Projects that we’ve deemed worth pursuing through backwards planning, a.k.a. asking “how,” should all roll up nicely when we ask, “why are we doing this?”

From my food example, let’s start with the option I ended up choosing – say it was to open my cabinet and eat something ready-to-go that I already had. Now, I can ask myself or get asked by someone else: Why did I just eat 2 spoonfuls of peanut butter and a granola bar? To get full as fast as possible. Why did you want to get full as fast as possible? Because I was hungry.

Notice that “why” will actually take us one step beyond our goal – back to the reason(s) for setting the goal in the first place. Back to the user problem.

Knowing why we are making decisions – because they all build a chain of dependencies that get us to our goal and ultimately solve some problem – will help us streamline and prioritize ongoing work. Asking “why” throughout the development process ensures that we’re grounded in user problems, focused on a big goal that makes sense, and on the same page about things that will get us there.

Since how and why are almost inverses, there’s some redundancy baked in, meaning you can make sure that everything we’re working on checks out. If while asking how’s and why’s you start seeing divergent answers, it’s a good sign that we need to step back, reassess, and realign our work.

There is, of course, no golden ticket for deciding which paths to go down. Adding real usage data, demographic information, qualitative data, stakeholder interests, etc to the mix makes things much more complex than my lil peanut butter example above. The how-why framework is meant to help us think through as many options and contingencies as possible, get on the same page with other stakeholders through open discussion about the options, and help narrow in on the paths that will help us reach our goals faster.

Our first instinct as product people is to go talk to our users, and then turn those inputs into product requirements. But should we always listen to our users? Andrew argues that there are two completely different approaches to involving users in finding opportunities, depending on whether your product idea fits in to existing user behaviour vs new user behaviour. Existing behaviour is things like Uber taking on taxis, Net a Porter moving fashion shopping online, etc whereas new user behaviour is things like the first iPod, iPhone and Twitter – totally new ideas and behaviours.

– Martin Eriksson paraphrasing Andrew Harder​ in ​Finding Product Opportunities with User Research

How annoying (but really, fantastic) that people use our product in so many ways. Turns out, product design isn’t about laying out elements in the most ideal scenario for the user that’s most convenient for you. As product designers, we have to foresee every outcome, and anticipate every potential user need.

Which brings me to another annoying epiphany: if you want to do it well, and account for every user, product design is so much more snarly and tangled than you’d expect going in. I began with a simple goal: to improve the experience on just one of our key product pages. However, every small change impacts every part of the product to some degree, and that impact has to be accounted for. Every decision is based on assumptions that have to be tested; I test my assumptions by observing users, talking to the team, wireframing, and prototyping. Many of my assumptions are wrong. There are days when it’s incredibly frustrating, because an elegant solution for users with one goal will complicate life for users with another goal. It’s vital to solve as many scenarios as possible, even though this is slow, sometimes mind-bending work.

– Meagan Fisher, “What I Learned about Product Design This Year

We tend not to think beyond our own experiences, believing we can extend what we know to the rest of the world. This makes us very (very) prone to solving problems that apply only to ourselves. When you design only for yourself, it’s not design; it’s indulging your vanity. Which is completely fine, but not what you’re here to learn.

– Stephanie Engle, in Intro to Product Design

Good metrics aren’t just about raising money from VCs … they’re about running the business in a way where founders can know how — and why — certain things are working (or not).