Menu

Posts tagged “product strategy”

Focus on product instead of technology

Laurent-Pierre Baculard makes some great points in WhatsApp Grew to One Billion Users by Focusing on Product, Not Technology:

Examples such as WhatsApp demonstrate that real-world innovation, in many ways, looks like an assembly line. At one end is a customer pain point or a potential new market. At the other is a product or service that solves the problem or addresses the market in a way nobody has thought of before. In between, people sit down and force themselves to examine the problem from a variety of fresh angles. Sometimes they tap the lab and bring a radical new technology to bear. But much more often they reach for pieces of technology that already exist and assemble them with new (or old) capabilities to produce a solution that turns the pain point into a delighted customer. Think of it as high concept meets whatever is lying around — an unconventional combination.

The problem comes when we reach for technologies that seem “cool” but can’t actually be linked to any real customer problem.

Yes, after a long break I’m giving the blog another shot. Let’s see how it goes…

How to make a product roadmap in 4 days

I just published a big post on our company blog about how we came up with our priorities and roadmap for Postmark for the next few months. From the intro to How we built a product vision and roadmap:

So, armed with some whiteboard markers, a mountain of sticky notes, and one very enthusiastic team, we set off to plan out the next few months of our product. In this post I’d like to give an overview of what we did, why we did it, and how it’s going to help us (and our Postmark customers!) in the coming months.

This one took a while to write and edit, and there’s some nice illustrations as well as downloadable templates, so take a look!

Build software to feed the world, not eat it

Kevin Slavin’s Design as Participation is one of those articles that stays with you for days. There are multiple ways to read it, but I view it as a thoughtful critique of my primary field of focus: user-centered design (UCD). There have been other discussions on this topic, most notably Cennydd Bowles’s excellent Looking Beyond User-Centered Design, and Mike Long’s Stop Designing for Users. Kevin’s is a worthy addition to the debate.

Kevin’s main thesis is that UCD is selfish (since it puts a user at the center of everything), and we should instead see users as active participants in a design:

Broadly, UCD optimizes around engagement with the needs, desires and shortcomings of the user and explores design from the analysis and insight into what the User might need or want to do. Simply, it moves the center from the designer’s imagination of the system to the designer’s imagination of the user of the system.

But we are no longer just using computers. We are using computers to use the world. The obscured and complex code and engineering now engages with people, resources, civics, communities and ecosystems. Should designers continue to privilege users above all others in the system? What would it mean to design for participants instead? For all the participants?

Also:

Some contemporary work suggests that we are not only designing for participation, but that design is a fundamentally participatory act, engaging systems that extend further than the constraints of individual (or even human) activity and imagination. This is design as an activity that doesn’t place the designer or the user in the center.

If this all seems overly academic, fear not, practitioners! Kevin shows several examples of “Design as Participation” in his essay, and also ends with this call to action:

A new generation of designers has emerged, concerned with designing strategies to subvert this “natural default-setting” in which each person understands themselves at the center of the world.

These designers do this by engaging with the complex adaptive systems that surround us, by revealing instead of obscuring, by building friction instead of hiding it, and by making clear that every one of us (designers included) are nothing more than participants in systems that have no center to begin with. These are designers of systems that participate – with us and with one another – systems that invite participation instead of demanding interaction.

We can build software to eat the world, or software to feed it. And if we are going to feed it, it will require a different approach to design, one which optimizes for a different type of growth, and one that draws upon – and rewards – the humility of the designers who participate within it.

It’s always hard to see one’s views challenged, but Kevin does it in the best possible way here. He understands UCD and why it came about, he presents a compelling argument about its issues, and then he shows us how we can do better.

I don’t think this means the end of UCD (or even that we should stop using its basic methods like personas and usability testing). But I do agree that we need to shift our thinking so that we’re less concerned about the success of an individual user (or groups of users), and more concerned about how different systems interact with each other. Alan Cooper touches on this topic in his wonderful essay The Edges:

What each organization has to do today is to regard the edges of its products with as much diligence and attention as they give the center. The quality of both their outside system connections (known as application program interfaces, or APIs) and their user interfaces demand levels of expertise and investment that have historically fallen short.

As nebulous as Kevin’s idea of “building software to feed the world” sounds, I like the sound of it. I like the hope and the desire to do good in the world that it communicates. We need to make that idea concrete in our daily design worlds, and I don’t think we quite know how to do that yet. But every practical mission starts with a grand vision, and I quite like this one.

Why it's more difficult to prioritize features than problems

Daniel Zacarias’s Moving from Solutions to Problems is a must-read for all product managers, and anyone who’s involved in product prioritization. Daniel’s main thesis is that prioritizing problems results in much better products than prioritizing features—and I wholeheartedly agree with him. He addresses many issues with focusing on features, but the one that really resonated with me is that it’s much harder to prioritize features:

Products and features are versions of a solution to a problem. What this means is that by thinking in terms of the former, the problem they’re solving gets more difficult to grasp. Either because it’s a non obvious problem, or the product/feature are poor solutions for it.

In practical terms, this makes it much harder to prioritize a list of features than a list of problems. There are added layers of indirection that make us evaluate priorities in a different way. It gets difficult to determine the intent and expected impact from a feature. On the other hand, a problem (“low number of transactions”) can more easily lead to an objective (“increasing number of transactions per customer per month by 30%”).

Quote: Chloe Green on the ROI of user experience

Numerous studies have found that every dollar spent on UX brings in between $2 and $100 dollars in return. Forrester revealed that ‘implementing a focus on customers’ experience increases their willingness to pay by 14.4 %, reduces their reluctance to switch brands by 15.8 %, and boosts their likelihood to recommend your product by 16.6 %’.

–Chloe Green, The business of user experience: how good UX directly impacts on company performance.

The benefits of prioritizing customer retention over revenues

Horace Dediu has a characteristically astute analysis of Apple’s business model in Priorities in a time of plenty. The part I’m particularly interested in is where he discusses how Apple prioritizes their product roadmap:

Conventionally, product development is filtered through a sieve of metrics, market sizing and impact on top/bottom income lines. These “financial” measures of success are considered prudent and optimized for return on equity (also known as the maximization of shareholder returns).

But this can be a toxic formula. The financial optimization algorithm always prioritizes the known over the unknown since the known can be measured and is assigned a quantum of value while the unknown is “discounted” with a steep hurdle rate, and assigned a near zero net present value. Thus the financial algorithm leads to promoting efficiency at the expense of creation. Efficiency may be the right priority when times are difficult and resources are scarce but creativity is the right priority in a time of plenty. And abundance is what being big is all about.

The difficulty is that creativity is hard to quantify, and therefore hard to measure, and therefore hard to prioritize—particularly in large enterprises. Horace speculates that “the creation and preservation of customers” is Apple’s primary focus (above revenues), which changes the way they prioritize:

Seen this way each centralized resource allocation question can be assumed to be prefaced with “In order to create/preserve customers should we…?”

This leads to answers quite different from questions that start with “In order to sell/profit more should we…?”

Much to digest here, particularly around the role of managers to identify the right balance for prioritization, and the right metrics to measure if your primary goal is, in fact, “the creation and preservation of customers”.

The real purpose of a Minimum Viable Product

In Jim Brikman’s post A Minimum Viable Product Is Not a Product, It’s a Process he explains the real purpose of following an MVP approach:

An MVP is a process that you repeat over and over again: Identify your riskiest assumption, find the smallest possible experiment to test that assumption, and use the results of the experiment to course correct.

When you build a product, you make many assumptions. You assume you know what users are looking for, how the design should work, what marketing strategy to use, what architecture will work most efficiently, which monetization strategy will make it sustainable, and which laws and regulations you have to comply with. No matter how good you are, some of your assumptions will be wrong. The problem is, you don’t know which ones.

And the crux:

The only way to find that out—the only way to test your assumptions—is to put your product in front of real users as quickly as possible. And when you do, you will often find that you have to go back to the drawing board. In fact, you’ll have to go back to the drawing board not just once, but over and over again.

This is one of the major problems with MVP-thinking as I see it in many organizations today. For many product managers MVP is unfortunately not a learning process, but just a fancy way of saying “v1”. And as we all know, the biggest lie in the enterprise world is “v1”. There’s never a v2. So many hide behind the “MVP” moniker to obscure the fact that they just want to get a thing out the door and move on. We’d do well to remind our teams that the real purpose of an MVP is to learn, not to complete.

The product forces that keep people on Facebook

Ben Thompson wrote a characteristically astute analysis of How Facebook Squashed Twitter. The whole essay is worth reading, but it’s this part in particular that stood out for me:

Facebook has developed its own interest graph that is far more powerful and effective and easier-to-use than Twitter’s ever was. Yes, Twitter still owns niches like NBA Twitter, and news hounds like myself (and most of you reading this article) will continue to find it essential, but for nearly everyone else in the world it is Facebook that is the first thing people check, not just in the morning but in all of the empty spaces of their lives. In short, it’s not simply that Twitter needs to convince users to give the service a second-chance, something that is already far more difficult than getting users to sign up for the first time; it’s that even if the service magically had the perfect on-boarding experience leading to the perfect algorithmically-driven feed, it’s not clear why the users it needs would bother looking up from their Facebook feeds.

This is a perfect example of The forces at work when choosing a product. In short, the progress-making forces that might push people from Facebook to Twitter are not nearly as strong as the progress-hindering forces that keep them on happily on the “good enough” that is Facebook.

The convergence of Product Management and User Experience Design

Melissa Perri in Changing the Conversation about Product Management vs. UX:

Product Management with no User Experience Design creates functional products that don’t make users excited. User Experience Design with no Product Management produces delightful products that don’t become businesses.

I have a few quibbles with this article (including the idea that the role of UX is to make users excited…), but I like this quote because it ties in with a common theme I write about: the importance of combining both user needs with business goals to create successful products.

Customer needs up and down the technology stack

I’ve seen Anshu Sharma’s Why Big Companies Keep Failing: The Stack Fallacy come up in my feeds a bunch of times over the last couple of days. I personally found the writing quite confusing, and had to read it several times to figure out what he was trying to say. I even drew a picture to help me.

If I understand the argument correctly, Anshu is saying that wherever your core business is in the technology stack, it’s easier to expand your market by going down the stack than up. Like so:

Stack Fallacy

This is obviously an oversimplification and leaves a lot of things out, but it was just a way for me to make sense of the article. That said, it’s this part in particular that stood out for me:

The bottleneck for success often is not knowledge of the tools, but lack of understanding of the customer needs. Database engineers know almost nothing about what supply chain software customers want or need. They can hire for that, but it is not a core competency.

The reason for this is that you are yourself a natural customer of the lower layers. Apple knew what it wanted from an ideal future microprocessor. It did not have the skills necessary to build it, but the customer needs were well understood. Technical skills can be bought/acquired, whereas it is very hard to buy a deep understanding of market needs.

In other words, it’s easier for Apple to take on Intel than it is for Apple to take on Facebook. Likewise, it’s easier for Amazon (AWS) to take on hardware manufacturers than it is for them to take on Salesforce. And the reason for this is that most companies understand the customer needs of the components their core business is built out of, but they don’t understand the customer needs of the businesses that other companies build using their components.

Update: This tweet from Peter Matthaei is a much better summary than the one I came up with:

.@RianVDM If your company uses something, it’s down the stack; anything that companies can build with your stuff is up the stack.

— Peter Matthaei (@mobivangelist) January 20, 2016

It’s an interesting theory, especially if you consider the logical conclusion that apps and services like Facebook and Salesforce (etc.) are at the top of the stack, and everyone not originally in the software business is going to have a really difficult time competing with them. I’d be curious to hear what others think of this…