Fundamentals of Digital Product Management
Products? Isn’t that stuff we shop for at the grocery store or other retailers? Things that we consume, or household items that we purchase to make our daily life easier?
Historically this is exactly how we’ve thought about products: as items or services in the analog world. But increasingly, product thinking has been applied to digital goods like music, books, and software. After all, these are the types of products that we’re buying more and more of on our smartphones, tablets, and laptops.
And we’re all buying or accessing these digital items via other digital products: web sites and mobile apps.
So what makes a product a product, and why should we care? Let’s explore some fundamentals of products to find out.
Products can always be made better.
Unless your product is milk, butter, or Coca-Cola, the product you work on is something that can be improved. In other words, products change. And if they don’t, they will most likely lose customers. So it’s not a matter of whether they change—successful products (with very, very few exceptions like the ones I noted) have to change. They have to evolve… or else, like organisms that fail to evolve fast enough, they die.
Think about the sites or apps that you work on. The very fact that you’re employed to design or develop something means that it’s not a static thing. Content and functionality change, the branding and interface need updating, or something changes in an operating system or on some hardware that impacts accessibility. In the digital space, the changing contexts of our products mean that they have to change swiftly just to hold their ground, let alone improve.
As people who work on sites and apps, we can contribute greatly to this improvement effort—but we don’t need to just follow orders and let others decide what should be better and why. The key to success with web sites and mobile apps is making the right changes for the right reasons and managing product change in ways that make a positive impact.
And the most important reasons for changing a product are driven by its customers.
Products serve customers first.
It can be too easy to update the content on a web site because someone in the organization, or a consultant, thinks it needs to be done. Similarly, it’s tempting to return from a conference and want to start applying a new technique or framework to your existing product in order to make it better. And even when we’re disciplined enough to go out to customers and check our design with them, it’s most often in the guise of usability testing: is it hard to use, or does the content or design make sense?
These are all important things. But what about the most important thing, beyond whether it’s state-of-the-art, has current and concise content, and is usable?
Is your site or app useful?
Usefulness is something that, ironically, is easy to overlook as we strive for technical and creative perfection. We get hunkered down in design and development, and then when we review our work we hope that it tests well for accessibility and usability. And all along the way, we tend to assume that because we’re doing the work for our bosses or our clients, it must be needed and deemed useful by someone. Because surely someone checked with customers first, right?
The fact is, the world is full of poor or failed products. And it’s not always because they’re designed badly, built carelessly, or are hard to use. There can be beautiful products that are built well and are intuitive to use. But if they are not designed to solve a problem for people, people will not find them to be very useful.
Usefulness is the most important thing to test for when it comes to knowing how or why you are designing a web site or mobile app. And it is the least technical aspect, as well.
Which brings us to user stories.
The foundation of product planning is the user story.
As noted above, designers and developers are often passionate people. They tend to be deeply focused on and obsessed with creative and technical solutions. Anyone who has attended a web or mobile conference has felt this energy. We simply love hanging out with each other to learn things, share work, and see new approaches to our work.
And this is all fantastic-- except when we let our passions drive our work too much. Designers and developers love to solve problems, but absent a problem presented to them by someone else, they’ll still find something to solve. Yet it might not be a problem that customers actually care about or a solution that, when in place, would help them.
But good customer research and feedback can yield real needs or insights that can dramatically shape the ongoing design and development of a digital product. And often these needs and insights are not apparent to the team that works directly on the product. They’re simply too close to it, to the point that they don’t have objectivity. Sure, they still think they can improve what they’re working on. But their opinions do not matter as much as the opinions of the customers who use the product. Customers’ opinions matter the most.
To make sure that product design and development is tightly coupled to customer needs and insights, the planning and delivery process needs to be managed in a way that keeps designers’ and developers’ focus on customers. This is done with user stories.
User stories break down and summarize customer needs and expectations into bite-sized targets that designers and developers can focus on. User stories do this via everyday language that describes what the customer is trying to do during use of the product. And equally important, a well-written user story will also include the impact of this need, or expectation on the organization providing the product.
As an example, a user story about a customer of a tech news and publishing organization should be focused tightly on 1) what type of tech news the customer needs and wants, 2) what the outcome of them getting that news is, and 3) what the impact is of them getting their tech content from your organization. For example:
“As a customer, I want to learn more about venture capital for tech start-ups. If I learn enough about this topic, I might decide to launch my own start-up, which could encourage me to purchase additional content about venture capital from your web site.”
A creative and technical team can take this user story as a starting point and begin learning a lot more about what they need to do to satisfy this customer. Perhaps the site’s content writers are not personally interested in thinking about venture capital. Well, they probably want to put that bias aside and start writing from the perspective of a user who is interested in venture capital. This is how a user story can impact content strategy.
And what about format? Perhaps the creative staff loves making videos. Well hey, that’s great—unless your customers don’t prefer videos, and instead want to read articles or listen to podcasts about venture capital. So digging deeper with these customers to verify preferences for content format could be helpful.
As user stories develop and multiply, try your best to keep them focused on customers’ human needs. Keep user stories as free of technical solutions, formats, and platforms as you can. Creative approaches and technical solutions can evolve and change quite a bit over time, even when customers’ most essential needs and expectations don’t change as rapidly.
Think about how Blockbuster might be faring today if they had maintained their creative and technical focus on meeting their customers’ most essential, human expectations. Instead, Blockbuster’s downfall was being overly focused on their long-established technology and approach of renting DVDs to customers from stores.
But Blockbuster shouldn’t have seen themselves as a business that rented DVDs from stores. They should have seen themselves as a business that rented movies, in whatever format best met that need at the time.
The DVD solution served Blockbuster very well for many years, but did not end up being a solution that was as enduring as their customers’ expectations to watch movies at home. If Blockbuster had been more creative like Netflix has been, they would have made the change to DVDs via the mail faster… and, eventually, movies via the Internet. All while the customers’ core expectation, renting movies for watching at home, remained constant.
The best unit of product success is the Minimum Viable Product.
Finally, when a creative and technical team is focused on solving user stories, the best way to do that is by delivering a Minimum Viable Product (MVP). An MVP is the least amount of work that is required to learn something new about meeting customer needs. And it’s not just the least amount of designed and developed product released to customers.
On the contrary, sometimes an MVP is a prototype that a group of beta testers can use to provide more feedback to the team. And in some cases, it can even be as abstract as a card-sort exercise. Early successes in the definition and design phases can be some of the most valuable advances during the entire product design and development process. Potentially it can save you lots of time designing and coding—and then redesigning and recoding— something that you might not have ever designed and coded that way had you only learned more from your customers earlier in the process.
But after prototyping and design, it’s also important to only build and deliver in small batches, too. Think of product development as steering a car on a highway. When we drive a car, we constantly make smaller and frequent adjustments to our course with the steering wheel. We do this because it’s a lot safer than closing our eyes, driving for several seconds, and then opening our eyes to see whether we need to make a hard turn to the left or right to sharply correct our course.
We would never think of driving a car like that! And yet it can be all too easy to gather some customer feedback early on, and then essentially close our eyes, hunker down, and design and develop a full-blown solution that meets those early findings--only to later learn that something in our customers’ expectations became more clear or changed along the way.
Smaller and more frequent course corrections in product design are just as important as in driving a car, and can save your organization or client from disasters that are just as dire as a car crash--or Blockbuster going out of business.
Focusing design and development on making small, yet constant, iterative changes to how they meet customer needs is the essence of product management. To be successful, product managers (or other roles who are willing to do product management work) should be focused less on solutions and technological details, and more on understanding core customer expectations and writing user stories that describe them, breaking those needs down into smaller needs and tasks that can be solved by the team.
Along the way, the practice of product management should facilitate frequent feedback mechanisms that help inform design and development whether it is still on track, as well as inform the organization or client about this progress, and how successful the solutions are once in place. Over time, product management sees the overall product cycle as one that includes discovery, design, development, and assessment, which simply leads to yet more discovery and additional design and development solutions.
Like the species on Earth that are most enduring because they evolve in the face of their changing environment, successful digital products evolve with changing market conditions and customer expectations. So don’t just design and develop beautiful, functional, accessible, and usable websites and mobile apps. Do all of this and more, anchoring your solutions to what is most useful, too.
If your sites and apps can meet and exceed customer needs, they will not only be successful—they might even change the world along the way.