I always love reading about IDEO’s process. In his post To Transform Your Industry, Look at Someone Else’s Owen Sanderson explains the concept of analogous research: a form of exploration that takes a team outside of its industry to find inspiration in the ways others have tackled similar challenges. He explains how they took some hospital staff to an airport to observe the customer experience:

We started at check-in. The hospital team was issued mock boarding passes and asked to check-in for their upcoming flights. They had the option of using a kiosk, their phone, or speaking to a real, live person.

Almost immediately the team began to discover parallels between the patient experience and the traveler experience. The surgeons on the team quickly noted how many different pathways there were for customers—options for families, those with disabilities, and frequent fliers. “We only have one option for our patients, but patients aren’t all the same,” one surgeon said.

I’ve found this type of research useful for digital products outside the service industry as well. The field of architecture, for example, can teach us so much about things like designing for permanence. This article is a good reminder that as product managers we shouldn’t just look at our competitors for inspiration. We should also study products in industries that might not look anything like ours, but aim to solve similar problems than we do.

Andy Johns wrote a 4-part series on product growth that is worth digging into. In Part 1: A Single-Minded Perspective on Growth he points out the trap many product companies fall into:

The point I’m making is that today’s startups very quickly fall into the optimization trap where they think future growth will largely come from optimizing their existing product. The better approach is finding the right balance between optimization and innovation since both methods can produce future growth.

This is why I am still, after all these years, such a big fan of the Kano model. It forces teams to think about these two questions separately: (1) what can we do to make our existing product better (optimization), and (2) what can we add to or change about our product to create unexpected value for customers (innovation).

This interview with Ryan Hoover from Product Hunt on how to develop products people love is really interesting. For example, here he makes a really good point about the importance of systems thinking in product management:

Most products can be broken down into a math equation, where multiple variables need to be true for it to work. Many newer product managers don’t break this equation down as much as they should. Then, they don’t test some of their hypotheses soon enough. If you have x, y, and z, and you’ve figured out the x and the y but you failed to resolve z, then it won’t work.

Sometimes people focus on the easier things. They resolve two hypotheses that are easier to figure out, and then defer the last one. A lot of people don’t think about user acquisition. They think, “We’re going to build an awesome product, we’ll get press, and we’ll launch it on Product Hunt and that’s it.” They should probably reverse it — think about distribution and marketing first, and then figure out how to build that into the product itself.

I also love their approach to experimentation, which can basically be summed up as “do it as cheaply as humanly possible.” Great interview.

This is an older article, but it was brought up in a recent thread on the Elezea Community (join us!) and I hadn’t seen it before. In Applying Leverage as a Product Manager Brandon Chu explains how PMs can have the biggest impact in an organization:

Managerial leverage is the idea that some things a manager does creates more output than others, and for each possible thing, the amount of output created per unit of time is its leverage. That’s the basis of how you should decide whether to do activity A or activity B.

When internalized, these concepts impart on PMs a sense of what matters most in their role. They have lots of choices in what they can do everyday — all of which produce some positive output- but developing awareness of where they have leverage is critical to their long term impact.

The crux of it is this:

Product managers exert the most leverage through vision and strategy — the rest is optimization.

Brandon shares a very helpful framework about the different types of work product managers do, and the best way to balance that work.

I’m a big fan of the product forces aspect of the Jobs-to-be-Done framework to help teams think through the challenges they need to overcome to get customers to adopt their product. In Product adoption: how to get customers to embrace your product the Intercom team discusses the product forces, as well as some strategies for overcoming those forces. For example, on decreasing attachment to the status quo:

What can you do to draw your prospects’ attention to your benefits over their feelings of belonging? It may be as simple as promising a feature they’re desperately missing (like online privacy) or mentioning the support options you have in place (so they don’t have to ask a friend for help).

It’s pretty interesting to see how different industries are adopting the product management role. In Product teams have taken national news organizations by storm. What’s happening locally? Christine Schmidt discusses how product is impacting newspapers and magazines:

“Product managers are the ones trying to think holistically and bring people together on how to move forward with a big idea,” Becca Aaronson, Chalkbeat’s director of product, said. “Anyone in a newsroom can do product thinking. It’s really about trying to think holistically about the needs of the audience, the mission and business interests of the organization, and technically how you’re going to get things done and bringing that together in a holistic way to create a comprehensive strategy for your organization.”

I like the reframing Sherif Mansour does in his talk Popular Misconceptions of the Product Craft. For example, here is his response to the common misconception that marketing-driven development is always bad:

As product managers we should always educate our teams on the value of great marketing, embrace the art of storytelling that infuses our marketing teams, and think about how we can bring that back to our teams. Whether you follow Amazon’s press release method, mock-up landing pages before starting a new feature, or do a box design exercise where you design the fictional in-store box for your new product, thinking about the Who, What, and Why of your product can help you build a better product for your customer.

I really like the NOBL team’s focus on Culture/Market fit in their article The Only Thing More Important Than Product/Market Fit:

Find yourself a healthy market, yes. Then develop a culture that can deliver product/market fit. Your culture is what produces your products and services. You know you have culture/market fit when both talent and customers flock to your company for who you are, even above what you make. You know you have product/market fit when legions of customers buy your product.

Without culture/market fit, sustainable product/market fit (at any size, scale, or maturity) is impossible.

They go on to describe four competing flavors of organizational culture, each with unique traits and competitive strengths.

There are some decent day-to-day work tips in Sierra Newell’s 7 Project Management Principles Product Managers Can Learn From. There’s one principle I wanted to expand on, and that’s “Define the scope and stick to it”. First, from the post:

Product managers should set the scope of their products’ development as early in the process as possible. Learning how to say no to product requests is a valuable skill. But it is also a reactive method of keeping your product’s development on track. Instead, be proactive. Define your product’s scope from the beginning, and keep development within that scope.

I know that “define the scope and stick to it” is fairly common practice, but I don’t think it’s a good way to build product at all. First, that principle tends only to define one side of the spectrum — how not to add scope. It doesn’t, however, talk about the need to sometimes reduce scope. If you define a “fixed scope” and say you won’t go over it, but then things take longer than anticipated (as they are prone to do in software) and you have no mechanism to deal with it, you’re going to get yourself in trouble. Because at that point, you “committed” to a scope that won’t change, presumably saying “no” to a bunch of things, and still you’re “late” in delivery.

This is why I’m a firm proponent of “fixed time, flexible scope” projects. Under that principle, you don’t lock down the scope for forever and ever. You commit to an initial body of work, and an expected timeframe. Then, if something happens along the way — a developer gets pulled into an emergency, or something takes longer than expected — you have a mechanism to deal with it. Since you didn’t lock down the scope, you don’t have to choose between being “late” or the team working themselves to death. You can reduce the scope of your work to fit into the time you gave yourselves to do it in.

There’s another scenario under which I would go even further and advocate for “flexible time, flexible scope” projects. There are instances where increasing scope (and time) is the Right Thing To Do for a project. For instance, if the choice is between a hacky way of implementing a feature, and extending functionality properly with future-proofing in mind, which would add two weeks to a project, I believe it’s pretty much a no-brainer that you need to add the two weeks.

This is why I think fixing scope is a dangerous practice. There are too many unknowns, too many variables, and too many things can change along the way. We shouldn’t let our process get in the way of good product decisions.