Strategy – Buy, Use, Love

Roadmapping and the challenge of predicting the future in an Agile world

“The future depends on what you do today.” ― Mahatma Gandhi

4803587118_0ba543352e_o — Creative Commons, source: https://www.flickr.com/photos/40875081@N06/

Presented below is the model I’ve landed upon after a decade of Product Management. When I reflect, I realize why Product Management is such a challenging and rewarding role – our job is to mitigate any risks that hamper future growth and demand for our products and, of course, predicting the future is impossible – great career choice, Ravi! 😊 The question that has constantly nagged me for ten years is, “Will someone care enough about what we’re building to pay us for it?”.

So here goes, hopefully some of this structure improves our (yours and mine) odds at anticipating the future (since we can’t predict it). A lot of this is nothing new in concept, so please excuse the verbosity below, but it can be hard to implement given all the crises and distractions that rock a Product Manager’s day-to-day life.

At the highest level, I believe there are some practices that need to be followed consistently for the product plans to be meaningful – the actual roadmap can and should change quite a lot over time as one tests their hypotheses with real customers through an Agile process.

First, it is key to define the customer (the paying entity) segment in terms of industry, geography, company size etc. etc. and think about the current size and future opportunity – this is not easy if we look at it from the “who uses our product today?” perspective – everyone ends up with customers they didn’t think they would get. For example, I inherited a team that ran Product Management for a widely used, highly scaled product used in every conceivable industry by companies of all sizes. Given the mind-boggling range of target markets, we deliberately started focusing on a specific industry not because of our past success but because we saw the potential room for growth in that industry according to market research. Other industries were important but did not offer as much opportunity for growth so the roadmap started heavily biasing towards solving the problems in this target industry. So, the moral of the story is that you have to make choices on who your customer is and focus your research and your development efforts… very rarely can you avoid making this choice so, get on it!

We need to then explicitly document and discuss the current tools, workflows and processes in our target industry and identify the users (people who touch the technology) in that workflow who we want to serve – in my experience this is best done as a collaboration between data analysts, user researchers, experience designers and PMs analyzing data and visiting or talking to customers to document their workflows (if you’re in a small company, the PM does it alone). Know that there could be multiple user types that benefit from our tools and they need to be explicitly called out. Of the user types, we need to explicitly define which users would be key to driving adoption and prioritize their problems first… for example, capturing user type A might create an ally inside the customer’s organization to drive adoption with user types B and C. Also, it is important to map out the dependencies between these users… sometimes the only way to deliver value is to solve a problem in a way that serves multiple users at the same time.

We need to then be explicit about the problems faced by our target user type in the target customer type (industry, geo, etc. etc.) – every need and feature request must be reworded in terms of the underlying problem. We should not jump to solutions (as tempting as it is) because everyone (from executives to PMs to development to Sales) needs to be clear on the user type, customer type and the problems we’re trying to solve. If there is a debate (which there will be) it should be about the importance of the problems we want to solve not a particular solution we want to implement – this is because every problem can have multiple solutions (some of which are not development tasks – better training, better customer support, better documentation, the PM’s personal cellphone number for every customer 😊 etc. etc.).

We also need to be explicit about prioritizing the problems, think in terms of two variables to score the problems for prioritization – pervasiveness and severity (higher the better). It is key to think about the pervasiveness and severity in the context of the target user and target customer/industry.

Once there is some common understanding of the prioritized industry, prioritized user type and the prioritized problems then the fun part of imagining the solutions, the new workflows begins. This is a cross-functional job and should include PMs, Technical Architects, Development, Experience Design, Analytics. The solutions can be scored for priority based on the following variables…

Differentiation – How different/better is it compared to the competition or the status quo? The PMs need to know the competitive landscape or current alternatives for this one (higher the better)
Cost – What is the R&D effort in terms of time and people? The Development Managers need to provide rough estimates (lower the better)
Risk – How certain are we that we know how to solve the problem? Sometimes there is need for pure invention so the risk is high. The development and software architects need to weigh in (lower the better)
Barriers to adoption (the silent killer of best laid plans) – How easy will it be for the target users, in the target industry, to adopt this solution? This is where experience design and user research can really provide some insights. (lower the better)

One can create a cumulative formula from the scoring described above to create a prioritized über list of solution proposals.

The final roadmap or backlog then is a list of prioritized solutions derived from the list of prioritized problems derived from a list of prioritized users derived from a list of prioritized customer types. Ideally, the prioritized customer types list changes least frequently and the prioritized solutions list changes most frequently as hypotheses are continuously tested through an Agile process.

This kind of list also makes it easy to evaluate the value and adjacency of potential acquisitions because, ideally, you’re looking to solve a broader range of problems for the same/similar customer type (since you may have already expended the energy and the cost of acquiring said customer and/or your go-to-market partners like marketing and sales are experienced at targeting and acquiring these customers).

One last thing is to maintain a list of mandates – these could be things like infrastructure updates, critical customer reported bugs, other unavoidable initiatives etc. that are non-negotiables. We all know they happen and its best to keep bandwidth free and have an open mind when they come and translate the mandates into their underlying problem statements.

I hope all of this helps… I have learned that having a structured way of thinking reduces stress, improves decision-making and brings sanity to a role that can feel like constant fire-fighting. The scoring/prioritization described above is still dependent on the PM’s judgement but breaking the process down to focus on customers, users, problems and then solutions clarifies the PM’s thought process and provides justification to get stakeholders and peers on board for execution.

If there are things here that don’t make sense to you then please write me a comment. I am a student of the art and craft of Product Management and I would love to learn from all your experience.

It’s the last mile that counts – Amazon Locker

A few weekends ago, I was catching up on the news and read about the thousands of runners finishing the last mile of the Boston Marathon. Running the last mile was a symbol of respect for the victims of the tragedy in April and the resilient spirit of a city and nation. As I was reading through the runners’ quotes in the story, I reflected on the importance of persevering and running all the way to the finish in my life and in my work.

I have always thought (and mentioned in a previous post) that the creation of great products is more akin to running a marathon than a series of sprints (no pun intended). Truly successful products and services go the distance and make sure that the promised value is actually delivered and realized by the end user. It is this focus that turns a product (technology + ideas + promises) into a solution (tangible value that customers would pay for).

As a product manager living in the San Francisco Bay Area, I have the privilege of meeting a lot of product people and discussing product strategies and challenges. Almost always I see a crisp definition of the problem that needs to be solved and a detailed description of the virtues of the product. However, more often that not, it becomes apparent that the product as-delivered does not really solve the problem unless the customer has specific abilities or skills, which may be difficult to possess or acquire. At this point the conversations get interesting and the big a-has come from working out how to turn capable products into a tangible solutions – charting out that last mile.

So when I stopped to reflect about an example that showed a clear understanding of the importance of running to the finish line, I landed on my recent experience with Amazon Locker. It takes the e-commerce experience literally to the last mile and makes sure that customers receive their purchases without having to worry about someone stealing the package or having to wait around for the UPS guy. Since I live in a condo building in an urban downtown, my deliveries sometimes have a tendency to find legs and disappear. Amazon Locker comes to the rescue; it’s a secure, single-use post office box at a convenient location (half a block from my building) to pick up packages… brilliant! Amazon’s obsession with operations is well known so I am not surprised that they thought about their ‘product’ as being all the pieces that need to come together for the customer to realize the value (quick, secure delivery of the package) of an online purchase.

There’s no doubt that creating amazing products requires an obsessive attention to detail. And, it seems like the most important of these details is the series of events that need to happen for customer to actually realize the promised value of the product… and the probability of these events happening in the real world. A good reminder that at the end of the day, it’s all about customer outcomes not products, and the persistence to make those outcomes happen – here’s to running that last mile.

Doing boring things well makes room for innovation

On a recent sleepless night when my daughter was struggling with a high fever, I found myself silently willing her immune system to kick the nasty virus’ behind. And that’s when it occurred to me, that while she gets compliments for her intelligence and her bubbly personality, no one ever compliments her on her immune system. Even though a properly functioning immune system is a prerequisite for her to learn new skills and to maintain her happy, light-up-the-room demeanor.

The next morning (in my half-woken daze) my neurons started connecting my thoughts about my daughter’s immune system with thoughts about product management and innovation. I kept thinking about whether I, and product managers in general, worry enough about their organization’s hidden systems. Do we think about the systems that might be ‘boring’ when described on a PowerPoint slide but are critical to support risk-taking and learning i.e. innovation?

I should clarify a few things at this point, I do not believe that well-oiled systems and processes can, by themselves, ensure the long-term success of a product or company. We all know that existing paradigms can shift dramatically and an optimized, efficiently running system can become irrelevant almost overnight. Also, I want to re-emphasize my belief that product management is about the what and the why and not the how – I just want to posit that the what and the why of systems that are critical to the survival, evolution and success of the product are (or should be) the concern of product management.

When I went looking for some examples of companies that do the ‘boring’ things really, really well, I found a couple of familiar names.

Apple and its supply chain:
I’m pretty sure that inventory stats won’t ever make the cut for any of the slides at an Apple keynote address, but my hunch is that Apple’s ability to run the tightest manufacturing supply chain in the world makes a lot of the innovations on the eye-catching slides possible. According to a recent report from Gartner, Apple is still #1 at masterfully orchestrating it’s entire supply chain and ensuring that its products are never sitting around gathering dust. In reality, Apple products generate so much demand that their main problem is assembling and shipping products at breakneck speed (hopefully in humane conditions). However, if the unthinkable were to happen and one of their products fails to create demand, the company won’t need to bleed money and take write downs like some of its struggling competitors. This must give them the ability to recover quickly from missteps and keep innovating.

Facebook and its uptime obsession:
Admittedly, uptime alone never made someone’s web-based business a success – sometimes stating the obvious is necessary. However, it is almost criminal to waste away one’s hard fought product-market fit because of sloppy reliability. It’s now historical fact that Facebook’s leadership has had an uptime obsession since the very early days. Their expansion, which seems almost instantaneous in hindsight, was measured and underwritten by an ability to ensure reliable uptime for all the new and existing users. On the other hand, the fates of services that came before Facebook but did not pay much attention to mundane details like reliability were sealed pretty quickly. Facebook seemed to have understood early that earning trust comes before earning money – the important thing is to remember that at all times.

A distressingly large number of products fail in the marketplace – some businesses are able to learn from such failure and succeed while others disappear. My belief is that the businesses that prevail understand that innovation is 99% execution and that the resilience that powers risk-taking and creativity comes from focusing on the mundane yet critical details.

Escape the ‘How’ prison with ‘What and why’

The motivation to write this post came from a great, raw, uncut interview with Steve Jobs, the then CEO of NeXT Computer, in 1990. Among many other insights, he recalls a thought that crossed his mind when he gave Sean Lennon a Macintosh as a birthday present, “Older people want to know how it does what it does but the young people just want to know what it can do”.

There comes a time in every product and industry’s history when serving the expert customer imprisons the product team into a cycle of ‘how’. The Product Managers respectfully ask folks ‘how’ something should work, implement things to comply with what they heard and then spend their days explaining ‘how’ things work in order to convince the expert to buy the new and improved product.

Of course, the inherent problem with this scenario is that in any sizable community, one will get a different answer to the ‘how’ question from every single expert user. So the final implementation and explanation of ‘how’ the product/feature works will be a compromise that satisfies noone completely and disappoints everyone slightly. The hope then is that one is able to manage the compromises effectively enough for the majority to still buy the product. In essence, one becomes a Compromise Manager instead of a Product Manager. A quick clarification at this point – obviously all complex projects require smart trade-offs to ensure maximum value is delivered with the time and resources at hand. The compromises that I write about here are about finding the least common denominator among many different implementation options, ending up with an insipid experience for all.

Now consider the scenario where the Product Manager reaches out to not only the current user but also the new user and the potential users and asks them what they would like to do and why (think outcomes and results not product features). In this scenario, there is freedom – freedom to implement the solution however one sees fit while making sure that the users can do what they want to do painlessly. Of course, the implementation in this case takes a lot of hard thinking as well as hard work because the Product Managers have to chart their own course. However, at the end of the day, they can then sell the product by talking about what all it can do and not ‘how’ it does it.

If these are the primary options, then why is it that Product Managers and product organizations choose the route of ‘how’ – why is it that so many wantonly imprison themselves in these user-generated courses of action that are guaranteed to produce unsavory compromises and ho-hum results?

You tell me…

P.S. – Steve Jobs… RIP, your biggest gift to the tech community is your way of thinking and yes, your products, they’re awesome too.

Product Management lessons from my newborn

It’s been a while since I blogged but I’ve been keeping busy since my last post… officially moved to the Bay Area, settled into the new job and, on August 30th, became a proud father of a healthy, beautiful baby girl. As a first-time parent, I realize that there is an infinite amount of learning ahead of me – this is merely the beginning. However, as I was spending yet another sleep-deprived night trying to decipher my daughter’s cues I saw some great product management lessons staring me in the face… literally. I’m finding lessons from my newborn and Mother Nature about how to launch a new product or business, nurture it and see it grow.

As a species, we’ve had the time to perform billions of iterations to come up with just the right handful of skills a human newborn needs to survive and thrive. It feels like there is a profound lesson here to guide those of us who struggle with new beginnings in other realms – like products and businesses. Mother Nature isn’t shooting for a ‘full-featured’ person at birth but it is very clearly setting the newborn up for success – with innate attributes and abilities (however few) to advantageously use its environment.

I just have a strong hunch that if most mere-mortal Product Managers were writing a Product Requirements Document for a human being… it would detail out the abilities of a well-adjusted, able-bodied 21-year old and explain why most of those skills are essential. That’s why I want to get this post out while all of these thoughts are fresh in my mind so I can look back at it someday when I am confronted with planning and launching something brand new.

Be irresistible
Babies are designed to be ‘cute’ – with their big eyes, large foreheads and chubby cheeks they tap into deep evolutionary programming in the adult mind and compel grown-ups to care for them and protect them. In fact there is ample research that points to the fact that all functioning adults (especially new parents) tend to be attracted to a baby’s cuteness – talk about precise target marketing. Babies may not be able to impress with insightful speeches, physical feats or sharp wit but they can and do mesmerize their own parents and caregivers. The lesson here is that, in the early days, being irresistible to the target demographic is more important than being ‘full-featured’ (quick side rant – as with people, products and businesses have to constantly learn and grow so there is no such thing as a full list of features on day one). Find the target customers of your product and business and understand them well enough to build something basic but truly irresistible – nothing else will do. This means minimizing the features to a point of discomfort and maximizing the beauty and elegance of the user experience to a point of obsession.

Fixate on the early adopters
The apparently underdeveloped senses of a baby are in fact highly tuned to identify and bond with their parents and primary caregivers. At a very early stage, babies make strong associations with the smells and sounds of their parents/caregivers and use this information to create strong loving bonds. There is scientific evidence that every time an infant feeds it reinforces the olfactory association to Mom in its brain. Even though babies are handed a set of underdeveloped senses, their focus on identifying and bonding with those who sustain them is pretty awe-inspiring and instructional. Early-stage products or businesses need just as much TLC as a newborn infant in order to survive, so it’s essential to fixate on the early adopters who will provide support and sustenance. There will always be critics who will seek to diminish your brand-new product by making comparisons to mature alternatives but, in the early days, you must ignore them. Once you have a relationship in place, the early adopters will help you grow stronger and become more capable.

Have an open mind and learn
Babies aren’t born with a lot of experiences to draw from but they are wired to learn – every waking minute they are soaking up information about their new surroundings, their parents and their own bodies. As a new parent, I am constantly doing things (some of them rather silly) to feed this insatiable desire for learning. It seems like Mother Nature is urging us product people to build products and organizations that are designed to learn from the get-go. Since all product groups and businesses operate with precious few resources, why waste them on building a few more premeditated features that may or may not resonate – why not spend the effort to instrument your product to be aware of when, where and how it’s being used and by whom? You can then use the data to spur deeper conversations with your users, understand why it’s being used the way it is and grow the product to make it more relevant, easier to use and more delightful.

Without a doubt, parenting is the most joyful and the most challenging thing I will ever do but I’m glad that this process is teaching me as much as it’s teaching my baby daughter. I am convinced that I can couple my insights as a parent with my renewed caffeine dependence to become a better Product Manager – I have a feeling that there are more posts like this in my future.

When and why is ease of use important?

This post is spurred by a few thoughts that have recently crossed my mind. One, it’s been an eternity since I’ve posted and the ideas for posts are now stacking up, withering and dying off… it’s time for some action. Second, I’ve recently moved from a quiet suburb of Portland, Oregon to San Francisco… life is not as easy(logistically) as it used to be but the energy of this big, busy, noisy city is exhilarating. And third, as part of this move we got rid of one of our cars and kept the Subaru (which I have mentioned in a previous post)… the Subie has a manual transmission and despite the traffic and the hills in our new town, we are happy it’s the car we kept.

How does any of this relate to a blog that’s apparently about Product Management? Well, these thoughts got me thinking about the value people place on ease of use – more pointedly, I am wondering if ease of use is the highest virtue to seek in products and services – in life?

Let me make it clear at the outset that as a Product Manager who admires products that people buy, use and love, I am not advocating for making things hard to use. No, no, no – I am merely wondering about the questions that need to be asked to understand if (when) ease of use is deemed valuable by customers and markets. I’ve writing about the questions that came to me but I’d love to hear your opinions…

Who is the target customer/user?
Early adopters (all Product Managers have met a few) love new products and services; they love figuring things out when they are difficult and duct-taped together. This makes them feel a sense of pride and they may gain credibility in their community for tackling a new product first. These users demand greater control so they can configure, customize and morph the product or service into sheer coolness. Of course, the more this demand for control is satisfied by the product creators (think massive options dialogs or unending variations on coffee drinks) the harder and more intimidating adoption becomes for the novice. I realize that it’s extremely challenging to peel away from the early advocates but, just like indie bands do every day, sometimes it makes good business sense to appeal to the masses. If the masses are the target customer, focus on ease of use – to these users easy is cool.

In what context is the product being used?

I recently read a great article that urges product creators (designers and managers) to empathize instead of trying to quantify ease of use (clarity) and value (usefulness). Empathy comes from identifying and understanding the scenarios of use and then building the product or service to fit these scenarios. Consider for example how quick service and cheap prices are more important at lunchtime on a workday and possibly a negative when you are trying to impress someone on a dinner date on the weekend. Understanding the real use cases makes it very clear that sometimes being easy isn’t the most pressing need.

What are the alternatives to your product?

In the early days of a product category, there might not be an alternative for a product or service. Soon enough, competitors will emerge and start outdoing each other with features/functionality and be rewarded by customers (the incremental value of each new feature is still high). It is truly a time when you build it and they come. Of course, at some point the various offerings become virtually indistinguishable. Then the easiest way to compete becomes price and we all know where price competition takes the market – the eroded margins make it impossible to fund innovation and slowly the most eager price droppers start hemorrhaging into obscurity. This is precisely the time to focus on the customer experience and ease of use. In a landscape of indistinguishable alternatives, how good a customer feels (or how little they are annoyed) becomes critical.

Just to be clear, ease of use is always a good thing but product management is about making tough trade-offs. And as we debate these trade offs, it seems helpful to keep in mind that products, like people, grow and the priorities one sets will need to change with that growth. For now, here’s to noisy cities and manual transmissions – check back with me in a couple of years.

Better or more?

Over the last two of months, I’ve studied and written about companies and people whose creations we buy, use and ultimately love. Products and services that are bought in droves, used incessantly and promoted for free. With the new year, I want to branch out into posts about specific questions that emerge from these profiles.

This time around, it’s about the choice between doing more (or different) or doing the same (hopefully better). A lot of the writing on this topic seems to have a strong success bias i.e. whichever option worked in a particular instance, that’s the option proclaimed to be the best. I want to understand when exactly a product business should do more (features, options, tiers) and when exactly it should focus and improve what it already does.

Even if the final decision is a combination of better and more (purple pill, anyone?); it seems clear that a Product Manager needs to intimately understand their situation (their customers, market and business) before deciding. The three parameters below seem most important to me – would love to hear your comments about others…

Landscape and competition
Many product businesses have to build more features (tiers, options) just to be considered during the buying process. It’s a pretty simple choice (btw, simple doesn’t necessarily mean easy) if the feature represents a fundamental barrier to entry to a market i.e. it passes the ‘minimum viable product’ test. However, things get more complex when this need is driven by competitive pressures because it is possible to succeed while ignoring competitive pressures (think Kindle vs. iPad). Reacting to any and all competitive pressures might actually be a recipe for disaster. The annoying part is that sometimes these features, while being decision criteria, are not really used day-to-day. I can see how this would irk the rational mind but I guess a PM needs to be just as rational (or irrational) as their customers.

Growing revenue vs. growing profits
The product business needs to know whether it wants to make more money in total or make more profits. These two might seem remarkably similar but they are not, since we all know that ‘one has to spend money to make money’. Almost anyone can make more money while spending more money but this can only be sustained for a short amount of time (think failed diversification-driven acquisitions). Making more money while spending less requires great discipline in picking priorities and having a clear understanding of how much is good enough for the customer to buy. Hopefully, all business plans seek a clear path to higher long-term profitability.

More customers or more from each customer
The product business needs to decide between pursuing more customers or higher-paying customers. If you’re a new business the choice is pretty clear – more customers are better than none. Typically, higher-paying customers demand more (options, tiers, features) within each product category because they have the means and expertise to sift through the options to pick one that is just right for them. On the other hand, the pursuit for more customers can be served by many bare-bones products (in different categories) to chase the long tail or a focused ‘good enough’ product that meets the most important needs of a very large market.

Self awareness and situational awareness are critical in personal life and it sure seems like they are essential in the pursuit of product nirvana. Creating products and services with the buy, use, love magic seems to hinge on seeking to know and knowing to keep seeking.