Sunday, November 30, 2014

When Apple unveiled its iPod digital music player back in October 2001, I dismissed it as a parity product. I already owned the Cowon iAUDIO CW100 MP3 player, loaded with my favorite tunes. There was Apple, generating great hype over the iPod as if it were a breakthrough product.

The idea of a portable digital music player was nothing new. The first mass-produced MP3 players came out in 1998. In late 2001, the concept may have been new to a lot of Apple customers, but it wasn't new to me. I proudly showed my MP3 player to friends when they gushed about the iPod.

Thus Apple's iPod was not an innovative product in and of itself. Years later, however, I realized the significance of ecosystem of which the iPod was a part. Apple had released iTunes (with technology purchased from SoundJam MP) and created the iTunes Store for finding and downloading music. Unlike Napster, it was a safe and legal way of distributing and acquiring music.

The prior way of playing portable digital music required a user first:

Connect a USB or other cable and transfer the file to a portable MP3 player (after installing the appropriate drivers).

No big deal for me. But the vast majority of users didn't know how, or want, to mess around with ripping CDs, installing drivers, or downloading and transferring files. They wanted to acquire and listen to songs, not files. Before Apple's iTunes and iPod, it was about "ripping", drivers, files, and transfers.

Apple had created an ecosystem. Its product managers and designers considered the entire set of user experiences, not just users' direct experiences with digital music players. If you viewed the iPod as a product in isolation, it wasn't innovative. The innovation was in creating a set of elegant (and legal) user experiences around acquiring and playing digital music.

The Lesson

This story makes you wonder: what is a product? Is a product a collection of features? Or is a product, in a sense, a set of user experiences? Product managers should focus on enabling users to have a set of experiences. Doing so requires considering (and building, if necessary) the entire ecosystem, not just a piece of it. The real innovations often lie outside of what product managers typically consider to be the product.

Thursday, September 18, 2014

Managing a website, whether the target visitors are internal to an organization or are in the public at large, is not merely a matter of slapping together some web pages and linking them together. It's also not merely about design.

No, managing a website includes such challenges as:

How do you elicit and prioritize the requirements for the website?

How do you position and market the website to the target audience?

How do you test your assumptions and continuously adjust to the needs of your target audience?

Note that those who manage any product face the same challenges. In his recently-published book, Website Product Management, David Hobbs teaches us how to manage websites as the "products" they are.

David was gracious enough to allow me to interview him about website product management and post his answers here. Enjoy!

Q. Why is product management important for websites?A. Organizations are usually stuck in the rut of thinking of their web presences as a series of projects. On the face of it this may not seem like a problem: after all, some changes to websites are big enough to warrant project management techniques. That said, the emphasis causes problems in a variety of ways: a) it leads people to believe that maintaining a website is more of a technical problem, b) a focus on what’s possible (or fits within a budget) rather than what’s important, c) it overlooks ongoing change (and probably even maintenance), d) it comes too late to integrators / development shops, e) and it leads to disjointed efforts. Product management needs to drive what all those projects are doing, and also to ensure that the organization is set up for other types of changes that are smaller than projects. Fundamentally, product management needs to make sure the web presence is coherent.Q. How is website product management different from product management elsewhere?A. First off, it’s extremely easy to make changes to websites. Of course, some readers may think “it’s not simple to change my website,” but that is a process or implementation issue. At its core, it’s easy to make website changes. Since it’s always “live,” if you make some simple changes to HTML (or other components of the site) then the whole world sees the change. But this could also be said of products that are delivered via the web. So the real differentiator is the natural inclination for a wide range of folks to feel like they “own” parts of the site. Sometimes the ownership is legitimate, and sometimes it is less so. Of course any product has a range of stakeholders, but usually pretty much everyone (and certainly every major group) in an organization feels they own chunks of the website. That’s the reason in the book I focus on the need for everyone to think of their website as a product, and not just some central team. Q. When managing a website, what are the very most important things teams can do to manage them more like products?A. For website product management, I break it down into three key ways of thinking: business first, long term, and broadly. So perhaps the most important thing teams can do is to consider each of these three aspects when considering any change. So when you are thinking about changes:Ask first what the business need of the change is. If that isn't clear, then you probably should not do it (even if it is “easy” to do).How will this work long term? Is this implemented in a way that will be difficult to maintain? Does it box you in for future change? Is it unnecessarily adding complexity to the implementation (or to the site visitor)?Is this just going to benefit one group, or will it help the website broadly? You don’t have to buy the book to get a free flowchart to better handle website change.Q. What activities of website product managers are the most strategic?A. I don’t necessarily advocate that someone has the title of “website product manager.” Depending on the size of the web presence, an existing role could take on this extra responsibility. Regardless, I advocate for broad acceptance within an organization of product management thinking. I think the most strategic activities are: 1) defining the vision for the site, and 2) rising above the day-to-day requests in order to set a solid foundation (what I think of as getting the bones right). There is a subtle dance between these two. You can’t just declare a vision that isn't implementable. Actually, you can and people frequently do — they just aren't very helpful and usually counterproductive. The vision needs to be inspiring, grounded in the business need, and implementable. To be implementable, you need to think about how long term and on an ongoing basis how your goals will be met (just implementing once isn't enough). In particular, one of the most damaging things that can happen to a web presence are one-offs, and these happen all the time. Frequently one-offs are lauded as victories. But they often lead to an even more disjointed experience. The bones need to be defined to accommodate the types of changes that will be happening and not break.

The assumption is that you have a great product idea and seek validation from customers before expending vast resources to build and bring it to market.

Indeed, it makes sense to transcend conventional approaches to making product decisions. Intuition, sales anecdotes, feature requests from customers, backward industry thinking, and spreadsheets don't form the basis for sound product decisions. Incorporating lean startup concepts, and a more scientific approach to learning markets, is undoubtedly a sounder approach.

Moreover, in larger organizations, sometimes further in the product life-cycle, everyone seems to have an opinion about such aspects of the business model as:

The most pervasive and urgent market problems the product should solve.

Whether the solution truly addresses the market problems.

What price customers would be willing to pay.

What tactics will most effectively drive prospects to buy.

Presumably, the "validated learning" approach of lean startup enables the organization to identify which opinions are factual and not mere speculation.

Validation in Practice

But let's consider what our naive lean startup practitioner (we'll call her "Cameron") does in practice.

Present the idea

Cameron puts together a slide deck, minimum viable product (MVP), or demo, presents her idea to one or more prospects, and eagerly awaits feedback. The prospects say, "I like it!" or "I would buy it!" Cameron feels warm inside, as the prospects have "validated" her and her idea.

Ask about the "pain point"

Since solving an urgent and pervasive problem or "pain point" is usually a prerequisite for product success, Cameron visits with prospects and asks them if they experience one of the problems she envisions her product would solve. "Yes," reply the prospects. Feeling "validated", Cameron does an internal high-five with herself.

Name a price

Cameron asks prospects what they would pay for a solution with the features she envisions for her product. Prospects "name their price". Or, in equally naive fashion, Cameron herself names a price and asks, "Would you pay X for the product?" Prospects reply affirmatively. Cameron can hardly contain her giddyness as her pricing assumptions are "validated".

Cameron feels extra special for having "gotten out of the building" to visit customers.

What's Naive about Cameron's Approach?

The results of all of Cameron's efforts are practically worthless, aside from the emotional affirmation she may feel. When you visit prospects, you don't get reliable information by posing hypothetical questions. When you seek validation from someone, you will tend to get it. Cameron unwittingly designed her interactions with prospects in a manner likely to confirm her preconceived ideas, and her interpretations of the results were naive. Let's call it "validation bias", an insidious psychological disorder that has infected the lean startup community.

Note: had Cameron conducted a survey, though seductive because it would have yielded quantitative data, the results would still have been suspect to the extent the questions were hypothetical and failed to confront prospects with real choices and commitments.

What's the Alternative?

If you want to be scientific in your approach to product decisions, you craft experiments and make falsifiable predictions, with the intention of testing, not "validating", the hypotheses and underlying assumptions.

Philosopher Karl Popper is famous for having championed falsificationism, a set of principles that shifted the emphasis from verifying scientific beliefs to ensuring they are possible to falsify via experiments:

According to Wikipedia:

"A statement is called falsifiable if it is possible to conceive an observation or an argument which proves the statement in question to be false."

In fact, Popper argued that a statement isn't scientifically factual at all if it isn't falsifiable.

Cameron could also work with her team to craft "digital" experiments and predict how those experiments will turn out. For example, her team could author "how-to" guides, downloadable on landing pages, that help prospects solve the problems she assumes they face. The team could predict how many people will visit those landing pages and how many people will proceed to download the guides. (To make prospects aware of the how-to guides, the team could run Facebook ads or Google AdWords to drive people to those landing pages and see if the predicted number of page visits and downloads materializes.)

The possibilities are endless, but they require a mindset that emphasizes falsifying product ideas and business model hypotheses, not "validating" them.

Tuesday, January 21, 2014

By now, if you're a product management, marketing, or technology professional, you've probably heard of ProductCamp. ProductCamp is an "unconference" where product management and marketing professionals teach, learn, and network.

ProductCamp depends on volunteers to organize it, propose and lead sessions, provide lively conversation and debate, set up and tear down the day of the event, and recruit sponsors to keep it free. Participants can propose sessions prior to the event, and participants vote the morning of the event to determine which sessions they will have the opportunity to attend throughout the day.

As I write this blog entry, registration for ProductCamp Austin 12 is open. If you're ready to commit to participating in the product management and marketing conversation, I suggest you register now. The slots usually fill up quickly. If you'd like to present or lead a conversation at the event, propose a session.

Is your company making ad hoc or informed, deliberate product decisions?

In the session, we'll look at five ways companies make strategic and ongoing tactical decisions about how they develop, market, and sell products and solutions. How do they decide what features to include in their products, what messages they will use to articulate the value of their products, what marketing tactics they will use, what prospective customers they will target, and other day-to-day choices?

We'll discuss the pros and cons of each method and explore other methods that may be more likely to result in product success.

I'd love to hear your perspective and see you at ProductCamp Austin 12.

Subscribe To

About Me

I'm a downtown Austin dweller with a passion for food, football (playing it, not watching it), knowledge, nutrition, investing, and a low-car lifestyle. In my professional life, I empower teams to make smart product decisions by applying design thinking, lean startup methods, and timeless marketing principles.