Required reading — or is it?

Requirements are, by definition, things which something requires. Humans require oxygen, nourishment, and companionship. My dog requires someone to scratch his tummy and boop his snout.

And yet: in tech product work, requirements is a term we’ve chosen to apply to our speculations and hypotheses about functions and features that we are betting will solve our customers’ problems and grow our businesses. And we sometimes pair requirements with the verb gather, as if these requirements are scattered about in the world, fully formed, and just need to be picked up and organized, like seashells.

I prefer a different framing. What is really required is to delight our users, solve their problems, and build our business. And that means we must explore, understand, ideate, articulate, strive, strain, fail, learn, try again, succeed. So the things we call requirements aren’t gathered; I submit that often they aren’t even required.

And that’s OK! In a healthy product-making environment, we’re learning all the time, so we’re necessarily making changes to our understanding of how our product puts our mission into the world. We thought a certain dashboard would solve our users’ need for timely information, but it turns out that mobile alerts are a better solution. So scratch the dashboard requirement — it was never required in the first place.

I think people in a healthy product environment understand this uneasy half-definition of requirement. The problem, though, is that in other environments, perhaps outside a product team, some may consider requirements literally, and evaluate the pre-written feature requirements as almost scriptural truths.

I’ve encountered processes in my career where the up-front requirements became the final measure of an endeavor’s success. After deploying a product to users, the team underwent a formal audit. Inquisitors from the PMO (who weren’t much involved throughout the product planning, discovery, and development) interviewed the product and project leaders, reviewed documentation, examined the product itself, and evaluated whether the requirements were met. If they were, the audit passed. If not, the team had to explain themselves, resulting in frustration and misalignment. If I recall, none of the inquisitors even asked what the product had done for the business or improved our customers’ jobs and lives.

I recently came across a document I wrote many years ago, when I was helping lead my then-employer through a shift to more product-aware operating models. It included a brief section labeled “On requirements.” Here’s an excerpt from this section.

—

Excerpt from “Developing Online Products in a Product-Managed Environment,” Company and date redacted, Jason Scherschligt.

On Requirements…

• Historically, we have established a complete set of functional requirements at the beginning of a project.

• Now, we’ll continuously work from a prioritized backlog of candidate features, with UX and product management teams staying 1-2 cycles ahead of development teams on product definition. 

• We will welcome changes to priorities, as they mean our understanding of what our customer needs has improved.

• We’ll use an experimental mindset and a “build, test, learn, repeat ” cycle throughout a product lifecycle to determine what is valuable for users.

• We can stop assuming we know what works before we release, and start holding ourselves accountable to the actual impact of our efforts.

—

I’ve gotten a lot of things wrong in my career. I think I got that one right.

On to the garden,

Around the Garden

To write requirements well, focus on outcomes

Check it out: How to Write Detailed Product Requirements without Killing Creativity - Nathan Udren

This post is a few years old, but its thesis is timeless. Engineer-turned-product manager Nathan Udren explains that a key to writing balanced, well-formed requirements is connecting them to the outcomes they represent.

I appreciate how Udren includes concrete examples that emphasize the business and user context of a requirement. He compares a rather sparse user story or requirement like “As a user, I want to be able to enter my credit card so that I can check out” to a context-rich story that’s nested within epics that roll up to an outcome — in this case, making the payment process easy for customers so the business can advance a goal of converting a certain percentage of users from trial users to paid users. With this context, the engineers and designers understand the business target and organize their work to meet a business standard. It’s a better way to write a requirement

Udren also depicts an outcome-oriented backlog, where the user stories roll up to the outcomes they intend to produce.

This model isn’t that different from the many other nested tree-like structures for product planning, but I appreciate his level of detail and his examples. I think his approach will be especially appreciated by engineers.

Yes to Roadmaps: Here’s why

Check it out: The Roadmap Dilemma, Noa Ganot

Roadmaps have fallen out of favor with some product managers, since they suggest certainty and since they are so often tied to dates. In the words of product executive and consultant Noa Ganot: “Almost every product leader I work with asks me at some point, ‘what’s the point in creating a roadmap that is about to change?’.”

Spolier alert: Ganot favors roadmapping. So do I, and so will you once you read her rationale.

A few highlights of her case for roadmaps:

• “But the fact that you don’t know enough, or don’t know for sure, doesn’t mean that you don’t know at all.”

• “It might sound weird, but the purpose of planning is not (only) to build a plan. It is an exercise worth pursuing even if you are throwing the plan away.”

• “Even if you feel comfortable with trial-and-error, people around you might not, especially when they are not in the details.”

• “Having some visibility, even with a proper disclaimer that things will surely change, is much better than having no visibility at all.”

Perhaps her wisest insight is that the work of creating the roadmap is itself an incredibly valuable exercise. It’s a forcing function that helps you think through implications, sequencing, and value.

Sure, but how do we start?

Check it out: How to Get Started with Outcome-Based Product Roadmaps - Roman Pichler

I’d just been engaged in some intra-SDG conversations about the challenges of shifting our customers’ teams to outcomes-based models when this article from product guru Roman Pichler showed up in my feed. Pichler starts by articulating a challenge with adopting goal-oriented product roadmaps: management’s attachment to feature- and date-driven plans.

He then offers a simple process for getting started in the face of this challenge:

1. Set an Outcome-based Goal for the Next Three Months

2. Use the Outcome to Determine the Features

3. Review the Approach (and repeat as necessary!)

4. Build an Outcome-Based Product Roadmap

I love how pragmatic this advice is. These are steps any product manager can understand and implement. If your firm is struggling to shift to outcomes-based roadmapping (and thinking!), Pichler’s “start with one outcome for a few months” is an excellent way to start.

On early smartphone cameras, product management superpowers, and building inclusive products (video)

Check it out: CPO Rising Series: Pinterest CPO on Building Inclusive Products and Empowering Users - CPO Rising Interview with Pinterest Chief Product Officer Sabrina Ellis (YouTube video)

I’m a sucker for interviews and profiles of successful product pros. This interview by Renee Niemi of Products that Count with Sabrina Ellis, CPO of Pinterest is insightful and at times even enjoyable. It’s well worth the 30 minutes.

Ellis has been a product leader at well-known tech companies, including Google. She is genuinely delighted by product work (“when I was an executive at Google people used to ask me what's your top priority and I'm like ‘are we having fun?’”), and that spirit of joy infuses the interview.

A favorite exchange is when Ellis reminds product managers to continuously reiterate the product’s goals (6:30).

The interview is a bit plagued by one of my pet peeves in product content, Bay Area-centeredness (great product work happens throughout the nation and world, of course), but I hope The Pollinator’s readers can overlook that. Ellis’s enthusiasm and experience make it easy to do so.

Outside the Box

Quick Draw is an experimental project sponsored by Google Labs to collect human doodles of everyday objects. You’ll have 20 seconds to draw what the prompt suggests (a zebra, a swimming pool, the ocean), and the AI will guess what you’ve drawn. Your drawings are building a data set to train a neural net. The best part is seeing what other contributors have sketched. As with many things involving AI and human creativity, I simultaneously love it and loathe it. But it is undeniably compelling. Check it out at https://quickdraw.withgoogle.com/.

About the Pollinator

• The Pollinator is a free publication from the Product practice at Solution Design Group (SDG). Each issue is a curated digest of noteworthy content and articles from across the internet’s vast product community.

• Solution Design Group (SDG) is an employee-owned digital product innovation and custom software development consultancy. Our team of over 200 consultants includes experienced software engineers, technical architects, user experience designers, and product and innovation strategists. We serve companies across industries to discover promising business opportunities, build high-quality technology solutions, and improve the effectiveness of digital product teams.

• The Pollinator's editor is Jason Scherschligt, SDG's Head of Product. Please direct complaints, suggestions, and especially praise to Jason at [email protected].

• Why The Pollinator? Jason often says that as he works with leaders and teams across companies and industries, he feels like a honeybee in a garden, spending time on one flower, moving to another, collecting experiences and insights, and distributing them like pollen, so an entire garden blooms. How lovely.