svpg blog

Product Management Then and Now

Mon, 23 Jan 2012 09:09:00 -0500

Occasionally in my work with technology product teams around the world, I run into product managers that are still practicing the role as it used to be defined back in the PC era of technology. These organizations are inevitably frustrated, as the role was not terribly effective and often not respected.

There are many possible reasons why these organizations have never moved forward. Perhaps the leaders are simply perpetuating what they learned many years ago. Perhaps the organization received "training" from one of the many non-technology firms that try to apply their models of the past to Internet-era companies. Perhaps the old role has been institutionalized in a formal corporate product development process.

In any case, after I explain the new role to the team, I find that it sometimes helps to highlight the key differences.

I think this probably works better in person, but I want to try this in written form. Let me say up front that this is a little bit exaggerated (but not much) to shine a light on the key behaviors.

Organization:

Old: Marketing
New: Product (Product Management plus User Experience Design), a Peer to Technology and Marketing

Education:

Old: MBA
New: Computer Science or User Experience Design

Spends Days:

Old: Writing Requirements Documents
New: Product Discovery / Pursuing Minimum Viable Product

Learns About Customer Behavior:

Old: With Focus Groups
New: With User Testing and A/B Testing

Makes Case For Project Funding Based On:

Old: A Business Case
New: Customer and Product Discovery

Reads:

Old: The Wall Street Journal
New: TechCrunch and GigaOM

Deep Knowledge In:

Old: How To Use Excel
New: His Customers

Loves:

Old: To Be The Boss
New: To Apply Technology To Solve Problems

Sits With:

Old: "The Business"
New: His Product Team (Designers and Developers)

When Things Don't Go Well:

Old: He Blames The Developers
New: He Blames Himself

Strives To Please:

Old: His Stakeholders
New: His Customers (because he's learned that's the only way to really please the stakeholders)

Makes Decisions Based On:

Old: Opinions
New: Data

Communicates With Stakeholders:

Old: With PowerPoint
New: With Prototypes

Attitude:

Old: Believes His Ideas Are Great
New: Knows At Least Half of Ideas Won't Work

Worries About:

Old: His Competitors
New: Taking Care Of His Customers

Secret Weapon:

Old: Killer Features
New: User Experience

Strives To Create:

Old: Profit
New: Value (because it's the best path to sustained profits)

This last point may not be so obvious to people and it is the subject of an upcoming article.

Measuring Innovation

Sun, 11 Dec 2011 20:07:00 -0500

Measuring innovation is a popular topic lately. Many product teams use Product Scorecards to keep their focus on outcomes rather than output. Eric Ries introduced the term “Innovation Accounting” for this purpose as well.

However, as much as I like and advocate for these techniques of measuring true improvement to your products rather than just adding features, if this is all you look at, over time you run the very real risk of falling into The Innovator’s Dilemma.

I am perhaps overly attracted to the concept of building enduring companies. I attribute this to having spent the first ten years of my career as a developer for Hewlett Packard, which back then was a company that prided itself on continuous innovation. But they had a tougher measure of innovation than many companies today. We were taught to measure the percentage of revenue that was coming from products and services introduced in the past few years.

My mentor during those years advocated that at least 50% of your revenue should be coming from products introduced in the past 3 years. He argued that even the best products have a natural cycle, and with good continuous improvement on those products you can stretch that cycle out, but still, every product has its day, and eventually competition and shifts in consumer behavior will take its toll, and sales and use will diminish.

Many large companies today use the “grow revenues through acquisition” strategy to building new sources of revenue. Certainly that’s one route, and occasionally the acquisition is one that is truly synergistic and could legitimately be viewed as a form of innovation.

But when people ask me for my favorite examples of truly strong product organizations, I cite the product teams that have proven their ability to not only improve their existing products, but even more importantly, to repeatedly deliver entirely new major streams of revenue for their companies. Examples include Apple, Amazon, Netflix and Zynga (in the case of the latter two examples, please don’t confuse recent questionable business decisions by the leadership with any fault of the product teams).

When I meet a company that is still getting nearly all of its revenue off of products introduced more than 3-5 years ago, I feel a real sense of urgency to help them get serious about innovation.

If you’re in one of these companies that has gone many years without new sources of revenue, and are harvesting the innovations of the founders, and you’re wondering if it’s possible for your company to learn these skills, one of my favorite examples today is the team at Barnes and Noble. They are now consistently producing highly rated new products and services, even while competing against two of the best product companies of our age. Their product team is giving their company a fighting chance to avoid the fate of the rest of their industry.

I hope more teams will track this additional measure of innovation. Interestingly, when I find companies that are very aware of this measure, they are much more open to the possibility of a pivot. Pivots are often the best source of these new major streams of revenue. Yet when you only are looking at innovation within your specific product, pivots are all too often viewed as a distraction rather than an opportunity.

Product Manager vs. Product Owner

Tue, 06 Dec 2011 11:11:00 -0500

All too often I run into companies that have resigned themselves to having two different people covering the product role.

Usually the way they split it is they have one person responsible for interacting with customers and stakeholders (which they often call the product manager), and another to interact with the development team and manage the backlog (which they usually call the product owner).

The reasoning is typically because they don’t have someone with either the skills or the time required to commit to covering both.

There are many “product managers” that are not technical enough to effectively engage with the developers, yet management hopes to utilize them. And there are many “product owners” that show no inclination or ability to get out of the building and interact with customers, yet management knows this is critical.

As appealing as this strategy may sound, I want to use this article to try to explain why this approach typically yields very weak product and little innovation.

I have written earlier that this approach has two common negative consequences. This first is that there is no clear owner (neither person takes responsibility for the product), and the second is a common lack of respect or understanding between the two (the “product manager” doesn’t appreciate the technical complexities, and the “product owner” doesn’t appreciate the customer’s pain).

However, this approach has an even more fundamental issue as well:

In order to make the many hundreds of large and small decisions a product owner makes every week, he needs to have deep understanding of the customers. Deep customer knowledge is what informs the decisions. It is actually the main thing a capable product owner brings to the party and it is what distinguishes him from the others on the team.

Similarly, when interacting with customers and identifying problems and opportunities, it is the knowledge of the technology and what is possible that informs the discussions and the potential solutions. This is what distinguishes a product person from other roles such as marketing, user research or sales, and why it’s essential that the product person has the direct customer interaction.

It is precisely this combination of deep customer understanding with the ability to apply technology to solve customer problems that enables a strong product person.

I know this doesn’t make it any easier to find people that are willing and able to do both, but I do hope that more company leaders come to understand how essential it is to find product people that can cover both aspects of the role.

MVP vs. Product Vision

Mon, 31 Oct 2011 04:40:00 -0400

Earlier I expanded on the notion of Minimum Viable Product (MVP) and I promised a series of articles that explores aspects of MVP that often cause product teams confusion. In this article, I’d like to discuss the relationship between the MVP and the Product Vision.

As a reminder, the Product Vision describes the types of services you intend to provide, and the types of customers you intend to serve, typically over a 2-5 year timeframe.

When I meet a startup, or begin working with a team that has an ambitious new project, we typically start with the Product Vision. I’m a big believer that if you don’t know where you’re heading, then you don’t have much chance of getting there.

However, it’s important to acknowledge that every Product Vision is predicated on a set of beliefs about what customers will find valuable, and that we hope can one day sustain a business or business unit. It’s important to get these beliefs out on the table and set about validating them.

One of the most common mistakes I find is that teams embark on product discovery and MVP but without a clear focus on the customers they are trying to serve.

So we typically start by identifying a core set of Earlyvangelist prospective customers. Remember, our intention with an MVP is not to try to please everyone, but rather to find a set of potential customers that believe in the vision, and are willing to work together with you to discover a solution (also remember we don’t expect them to give us the solution – we just need to be able to test out whether our solutions work for them).

Our hope and intention is to try to come up with a product that can make our product vision a reality.

That said, it’s possible that we’ll discover along the way that our hypotheses about value just aren’t reflected in our customers, or we might discover we need to pivot to either different customers, or different solutions, or different problems to solve.

But mainly we’re hoping to iterate our way to a solution that these Earlyvangelist customers find enough value in that they’re willing to buy, they can figure out how to use, and you can deliver with the time, talent, technology and money you have available.

I don’t mean to gloss over the product discovery techniques of this rapid iteration using various MVP Tests - I’ve written about this many times, and more will come in the MVP context – but if we view the MVP as the smallest possible product we could discover that’s sufficient to sell to our Earlyvangelist customers, then there’s still going to be a long way from this MVP to the product described in the Product Vision.

Just because our Earlyvangelist customers will buy something doesn’t mean that everyone in the target market will buy. If you remember the technology adoption curve, the Earlyvangelists are just the small but highly motivated group that’s really feeling the pain, and desperately need a solution. To move from Earlyvangelists to more mainstream customers (early majority), we’ll need to continue to develop the product (typically by expanding the scope of customers we’re trying to serve, and doing product discovery to identify solutions to their needs).

This is why it often takes weeks or months to discover the MVP to serve the Earlyvangelists, but then it can take years to expand the offering to the point that it meets the much broader market needs, and fulfills the product vision.

So, while the Product Vision inspires the MVP, the MVP precedes the Product Vision and is usually the first real test of the Product Vision.

Probably one of the most visible examples of the relationship between the MVP and the Product Vision could be seen with the original iPhone. While there were many prototypes (MVP Tests), the original iPhone device (what Apple believed was the MVP) had many limitations (even missing copy-paste) but for the Earlyvangelist customers, they could see the vision, they found real value, and they embraced the device. But of course that was just the beginning of the product line and not the end. Each release since then has expanded the target market to meet the needs of a broader range of customers, and come another step closer to realizing the product vision.

Hopefully this all helps to put MVP Test, MVP and Product Vision into perspective. There is lots more to talk about but I’m hoping this can serve as a foundation. Please continue to keep your questions coming.

Lean Thinking

Thu, 13 Oct 2011 15:13:00 -0400

A while ago I posted an article on people that I think have something really valuable to say to product leaders. One of those people I discussed was Eric Ries, author of the blog http://www.startuplessonslearned.com. I also promised that I’d share a glossary to map the nomenclature and concepts he uses with the terminology I use in my writing and my work with product teams.

I held off a little on this because he has been working on a book which has just recently been published, called “The Lean Startup” and in this article I’d like to discuss the key concepts in the book and provide that mapping.

First, I have to say that I consider this one of the best new books on product in a very long time. Since I read it I’ve been encouraging everyone I work with to buy the book. Eric has a strong mind and is also a gifted writer, and the result is a powerful combination.

I think the book is relevant whether you’re new to product or experienced. I have been working on technology products for about as long as anyone, and I added several techniques to my arsenal, and I’m pretty confident you will find real value in the book as well.

I also believe the majority of the material in the book is applicable to all technology product teams, and not just early stage startups.

One worry I had going into this book was that he might try to take the concepts of Lean Manufacturing and force fit them into a technology product innovation context, but he really doesn’t do this at all. He takes some of the relevant principles from Lean Manufacturing and applies them where it makes sense. His key premise is that Lean Manufacturing is about removing waste, and since one of the most egregious forms of waste is to build a product nobody wants, maybe we can apply some of the techniques to reduce the waste in creating products.

Using my nomenclature, I consider this a book primarily about product discovery. I define product discovery as the process of coming up with the minimum viable product, and that’s at the heart of the book. But more generally he’s trying to share techniques for building a sustainable business: “The goal of every startup experiment is to discover how to build a sustainable business around the company’s vision.”

Glossary of Concepts:

Many of the terms we each use are essentially the same: validated customer learning, customer/user testing, pivots and split testing are examples, but there are some places where he uses different nomenclature, and I highlight these here (term that Eric uses, term that I use):

Build-Measure-Learn Feedback Loop = Product Discovery
Minimum Viable Product (MVP) = MVP Test
Innovation Accounting = Product Scorecards
Cross-Functional Teams (small but secure, empowered and motivated) = Dedicated Product Teams
Customer Archetype = Persona
Value Capture = Monetization Strategy
Small Batch = Incremental/Continuous Development and Deployment
Large Batch = Big Bang/Waterfall
Early Adopters = Earlyvangelists
Portfolio Thinking = Portfolio Grooming
Metrics = KPI’s (Key Performance Indicators)

There was one key term that the book uses differently than I do, and that’s the term “prototype.” Eric associates the term prototype with the engineering perspective, where a prototype is mainly about assessing technical feasibility. He tries to draw a distinction between an MVP Test and a feasibility or usability prototype here: “Unlike a prototype or concept test, an MVP (Test) is designed not just to answer product design or technical questions; its goal is to test fundamental business hypotheses.”

In my use, there are different forms of prototypes for testing different things – a feasibility prototype would address technical risks, a usability prototype would address interaction design issues, but the primary purpose of prototyping in product discovery (user prototype or live-data prototype) is intended to assess the value of the product.

His big point is that the most important thing is to assess whether or not the product can support the business – especially value and growth. And he’s trying to point out that just because something’s usable or feasible doesn’t mean people will want to buy it or that you can build a business around it. In my writing, when I use the term “prototype” that’s precisely what I’m focused on as well.

Great Discussions

The book ties to cover quite a broad range of topics, some lightly and others more rigorously, but several of the discussions were especially noteworthy:

- Minimum Viable Product

Most of the book is about this concept of rapidly testing and iterating our way to coming up with something that will sustain a business. The book shares quite a few good techniques for validating the market/demand, validating the solution, and validating the growth engine.

- Pivots

One question I get from so many teams is when to pivot and when to persevere (iterate), and the book talks about this explicitly as well as implicitly with good real-world examples throughout. Also a very useful taxonomy of types of pivots. Overall I’m hoping this book goes a long way to helping teams not only recognize a pivot opportunity, but embrace them.

- Growth

For many teams I meet, establishing strong value in the product is only half the battle, and they often struggle trying to get their growth engine working to the point that they can acquire new customers in a way that you can build a viable business around. The book has a good discussion of the main ways technology products grow.

- Innovation Accounting / Product Scorecards

Probably my favorite section of the book covers what Eric calls “Innovation Accounting.” There are several very relevant examples from companies you’ll recognize and the book does a good job of highlighting some of the big benefits as well as the pitfalls of business and product KPI’s. This should be required reading for anyone responsible for coming up with the scorecards for their teams.

- Importance of Qualitative and Quantitative Learning

A hot button for me is when I meet people that only believe in one or the other of qualitative learning or quantitative learning. But Eric truly seems to understand the importance of each: “Qualitative learning is a necessary companion to quantitative testing,” and “poor quantitative results force us to declare failure and create the motivation, context, and space for more qualitative research.”

- Sustained Leadership

I’d like to end this article with probably my favorite quote from the book, which I think does a good job summarizing why these techniques are so essential to modern product teams: “Sooner or later, a successful startup will face competition from fast-followers. A head start is rarely large enough to matter, and time spent in stealth mode-away from customers-is unlikely to provide a head start. The only way to win is to learn faster than anyone else.” Amen.

The Greatest

Wed, 05 Oct 2011 21:45:00 -0400

It may have been Muhammad Ali in the boxing world, but in the product world, it’s hard to argue that Steve Jobs wasn’t the greatest ever.

He tackled immensely difficult problems, and generated products that came to define their categories and literally change the world. Just one such product can define a career, but a stream of them defines an icon, and leads to the most valuable company in the world.

I can’t imagine a world without Apple, and I am grateful that I don’t have to.

I know that the talented employees at Apple have been preparing for this eventuality, and have been practicing by asking themselves “what would Steve say?” for a while now. While I do not believe he can be replaced, I do think his lessons can be learned, and his passion can live on.

My sympathies to all of the employees of Apple, past and present, that knew and worked with him.

Minimum Viable Product

Wed, 24 Aug 2011 20:51:00 -0400

One of the most important concepts in all of software is the notion of minimum viable product (often referred to as “MVP”). But if you’ve been around software products for a while, you know that term is used in many different ways, and while the term intuitively resonates with people, there’s often a lot of confusion about what this really means in practice.

You can find it defined as the smallest possible experiment to test a specific hypothesis, all the way up to the the tangible realization of a product vision.

I’m not arguing here that any of the definitions out there are right or wrong, but I am arguing that the confusion is not helping product teams, and this is simply too important of a concept to have so much ambiguity.

I have long defined minimum viable product as the smallest possible product that has three critical characteristics: people choose to use it or buy it; people can figure out how to use it; and we can deliver it when we need it with the resources available – also known as valuable, usable and feasible.

I love the concept popularized by Eric Ries of the smallest possible experiment to test a specific hypothesis, but I refer to that that as an “MVP Test” so that people don’t confuse an experiment with a product.

But beyond the definition, it’s equally important to recognize that it’s not enough just to think you have defined MVP (which is what most product owners do – it’s their opinion), you need to have evidence that you have this – we call this validated customer learning.

Further, I define product discovery as the process of how we identify the minimum viable product and get this validated customer learning.

While my definitions above hopefully sound straightforward, I still get many questions from product teams about this critical concept:

How do we rapidly converge on an MVP?
How do we know we have actually achieved MVP? What level of “proof” do we need? How many customers need to agree to buy it?
Is the MVP intended to be something that we sell, or is it just an experiment?
If it’s something we intend to sell, what if a customer won’t buy it? Does this mean it’s not MVP?
Who is responsible for discovering the MVP?
Who makes the decisions regarding MVP?
How long should we keep trying to achieve MVP before we give up?
What should we do when we identify a pivot opportunity?
Do we need to wait until we have identified MVP before we start building production software?
Is MVP the same as “minimum product?”
Is MVP the same as “product vision?”
Is MVP the same as MMF (Minimum Marketable Feature)?
What happens after we have achieved MVP?
How do I go from MVP to backlog items?
Is MVP a moving target? Can I lose it once I’ve found it?
Is there only one MVP for a given market or could there be many?
Do we handle MVP the same way for products for consumers as we do products for businesses?

These are all important questions and I can understand why people can get confused, so I thought I would try to address these with a series of articles. I’ll do my best to make this abstraction real, so you can see the value and hopefully put this fundamental concept to work for you.

Please feel free to send me additional questions and I’ll try to incorporate them in as well.

Competition

Tue, 02 Aug 2011 15:55:00 -0400

One of the constants in our business is competition. Very occasionally you find a company that has established a monopoly position, but for the most part, if the market you’re serving is a real market with real customers with real needs, you either have competitors already, or you will very soon.

Yet so many companies struggle to determine how to respond when a new competitor emerges. They are worried that this competitor will somehow make their product offering obsolete, or undercut their pricing, or one way or another steal away their customers.

As a result, many companies resort to a cat and mouse game with their competitors. They stress over each other, they chase each other’s features, and they try to market against each other’s weaknesses. All of these responses to me only serve to distract them from what they really need to be doing.

What these companies don’t really understand is that customers don’t leave us for our competition; they leave us because we fail to meet their ongoing needs.

Please consider this. Think about the companies you know that that thrive in the face of many strong competitors. And think about the companies you know that have lost their customers.

I try to get the companies that I work with to focus their energies on providing real value to their customers. Unless they do this, their customers are probably just waiting for a good opportunity to leave. On the other hand, when your customers know that you continuously strive to deliver great solutions and great service, it generates true loyalty. The kind of loyalty that you’ll need when you make mistakes, or when new competitors emerge.

It is amazing to me how much energy goes into chasing competitors, yet how little energy or resources goes towards addressing the very real concerns of customers.

It is true that markets evolve and our customer’s needs and expectations can change over time. Especially with major technology shifts, customers that were once happy with your product may no longer be satisfied. A common example is when customers now expect mobile access.

While many product leaders and company execs stress out too much about their competitors, I also find many that completely ignore competitors. Usually because they assume their competitors can’t possibly be as smart as they are. These people also I think miss an opportunity.

I’m a big believer in having product leaders understand all of the players in their market. I think you can learn valuable lessons from all of your competitors.

My suggestion is that the product leader should study each competitor and identify the three key things that they think the competitor does that provides real value for their customers, and the three major areas where they think the customer’s needs are not met. The strengths and weaknesses may be in the functionality, or it may be in their policies, or their customer service, or pricing, or anything else. It’s important to take the holistic view when evaluating competitors.

The key is to constantly drive value for your customers. It’s really the only way I know to competitor-proof your business. So stop chasing your competitors and start focusing on providing real value for your customers.

Project-based Funding

Sun, 24 Jul 2011 09:07:00 -0400

If your company is one that still allocates product development funds based on approval of projects, then you still have the old “project-based funding model.” This is mostly a situation in either large companies, or those that have an IT-style legacy, but the mindset often exists even in small companies too.

Unfortunately it’s a very bad model.

I have written about this before but not as explicitely as I am here.

There are three fatal problems with the project-based funding model:

You very likely have no real clue when you propose a project for funding if you should really even be pursuing the project. Even though you might pretend otherwise with a cleverly crafted “business case” the truth is that you probably have no real evidence if your customers are going to like this, and you probably also have no real idea how much it will cost to build (because at the project proposal stage, you don’t even know what “it” is). So you don’t know the revenue and you don’t know the required investment, so of course the ROI estimate is less than meaningful.
Creating strong products is not a series of projects that come in sporadic bursts of a few months each over several years. Strong products result from getting your concept in front of customers and rapidly and continuously learning and improving. Further, to make this progress, you need not just continuity of investment, but also continuity of the team.
Very often in good product work we find that our initial ideas are not quite right but if we change direction somewhat, which we call a “pivot,” we can often uncover major new sources of revenue. These are the very sources of revenue that companies depend on for another several years of rapid growth. However, with project-based funding, the consequence is that this sort of pivot is effectively discouraged.

The project-based model is not only bad from the product and customer point of view. The model is very bad from a financial point of view.

The financial business cases that the decisions are based on are unacceptably flawed. The inefficiencies and lack of velocity caused by the lack of continuity means we get less from our money. The accountability so desired by finance is missing because you don’t know if the problem was that the team did a poor job executing, or if the problem was that the leaders picked the wrong project to pursue. And most importantly, it doesn’t generate the business results we need or expect.

The main alternative to the project-based funding model is the dedicated product team model. In this model, rather than funding specific projects, you instead are funding product teams which work on distinct products.

Rather than have the teams focus on delivering specific features or projects, they are accountable for delivering against prioritized business KPI’s. The team decides which features or projects or other work is necessary to deliver the necessary business results. Some of the ideas will pan out and others will get quickly killed. The product team is empowered to decide what is most appropriate to deliver, yet they are also held accountable to the results.

Product teams can be funded and staffed at any time, but they usually last for at least a year or two. You can also decide to increase or decrease the allocation of staff to that team as the needs of the business change.

One of the reasons that the project-based staffing model is often found in old IT-style legacy companies is because it fit well with the outsourcing model of staffing projects and the associated "Statements of Work" style of working. But just to be very clear, this model doesn't work for product companies for the reasons above and more.

In any case, the dedicated product team model will not only help your money go further, but most importantly it generates better results in terms of speed to market, degree of innovation, and business results.

This is just one of the important dimensions of product portfolio planning. If you think your company has issues in this area, you'll want to read Principles of Product Portfolio Planning, Dedicated Product Teams and The Product Scorecard.

Product Evangelism

Sun, 17 Jul 2011 18:18:00 -0400

In my last article I wrote about the importance of product passion, and I said that one of the reasons this passion is necessary is for product evangelism.

Product evangelism is, as Guy Kawasaki put it years ago, “selling the dream.” It’s helping people to imagine the future, and inspiring them to help create that future.

If you’re a startup founder or CEO, this is a very big part of your job, and you’ll have a hard time assembling a strong team if you don’t get good at this.

If you’re a product manager at a large company, unless you’re good at evangelism there’s a very strong chance that your product will get killed before it sees the light of day, and even if it manages to ship, it will likely go the way of thousands of other large company efforts and wither on the vine.

I’ve always believed that the product owner needs to be the product evangelist for the team. If the product owner is responsible for the backlog, and the backlog is what the team is working on, the product owner needs to ensure the team understands the reasons behind the backlog items.

This not only helps the developers do their work, but more importantly, it motivates the team to actually want to do this work.

There are several techniques to help communicate the value of what you’re proposing to your team, colleagues, stakeholders, executives and investors. Here are my top 10 pieces of advice for product leaders in terms of selling the dream:

Build a high-fidelity prototype. For many people, it is too hard to see the forest through the trees. When all you have is a bunch of user stories and backlog items, it can be very hard to see the big picture and how things hang together (or even if they hang together). A prototype let’s them clearly see the forest and the trees.
Share the pain. Show the team the customer pain you are addressing. This is why I love to bring developers and stakeholders along to user testing. For many people, they have to see the pain themselves to get it.
Share the vision. Create a product vision showing where you hope to be in 2-3 years. Not a list of features and not a spec, but rather, what types of services do you intend to provide, to what types of users? A set of product principles complements this well to share more of the nature of the product you’re working to create.
Share learnings generously. After every user test or customer visit, share your learnings – not just the things that went well but share the problems too. Give your team the information they need to help come up with the solution.
Share credit generously. Make sure the team views it as their product, not just your product. On the other hand, when things don’t go well, step forward and take responsibility for the miss, and show the team you’re learning from the mistakes as well. They’ll respect you for it.
Learn how to give a great demo. Especially for stakeholders, we’re not trying to teach them how to operate the product, and we’re not trying to do a user test on them, we’re trying to show them the value. A demo is not training, and it’s not a test. Yes, it’s a form of sales. Get good at it.
Do your homework. Your team and your stakeholders will all be much more likely to follow you if they believe you know what you’re talking about. Be the undisputed expert on your users and customers. Be the undisputed expert on your market – your competitors and the relevant trends.
Be genuinely excited. If you’re not excited about your product, you should probably fix that either by changing what you work on, or changing your role.
Learn to show some enthusiasm. Assuming you’re genuinely excited, it’s amazing to me how many product leaders are so bad and/or so uncomfortable at showing enthusiasm. This matters. Absolutely be sincere, but go ahead and let people see you’re genuinely excited. Enthusiasm really is contagious.
Spend time with the team. If you’re not spending face time with every designer, developer and QA person on your team, then they can’t see the enthusiasm in your eyes. If your team is not co-located, you’ll need to make a special effort to travel there and do this at least every couple months. Spending a few minutes with every last person on the team pays off big in their level of motivation and as a result, the velocity of the team. It’s worth your time.

Note that if your company is mid to large in size, then it’s normal to have product marketing that plays the role of evangelist with your customers and your sales force. You still may be called on to help out on the big deals and big partnerships, but you’ll need to focus your evangelism on your team because the best thing you can do for your customers is to provide them a great product.

Product Passion

Mon, 27 Jun 2011 01:07:00 -0400

One topic I’ve never written explicitly about is the need for product passion. I’ve referenced it at the top of the list of traits for good product leaders, but it’s easy to take this for granted especially since the people I surround myself with professionally are generally very passionate about products.

However, lately our industry has seen a resurgence of what I’ll call “product frenzy.” I hesitate to use the term “bubble” because I’m not sure if it is or not, but certainly there is a form of frenzy going on with people starting product companies at an incredible pace – more than I remember in the late 1990’s.

In the late 1990’s we had many people coming to Silicon Valley to try to get rich quick. They didn’t care what they were working on as long as they thought could flip it quickly for big profits.

While I think there is some of that going on again now, I am seeing a different sort of problem, that is fueled largely, but not exclusively, by the new mobile market.

Instead of trying to build a company around a vision, many people are essentially equating building a mobile app with building a company. Build a great app, people will love it, someone will buy us.

Essentially the table stakes for starting a company have dropped. It can cost very little to build a mobile app. Of course, a few of these apps are impressive while most are not, but that’s not really my point in this article. Here I wanted to talk about the difference between those that are pursuing a vision where the app is but one step, and those are just chasing their latest app idea.

Let’s consider three recent startups:

- Read It Later indeed has a very successful mobile app, but founder Nate Weiner is in hot pursuit of a much bigger prize; to be the leader in the space of content shifting – being able to read your favorite content on whatever device you want, whenever you want to view it, online or offline.

- Flipboard has created one of the best original apps for the iPad, but founder Mike McCue views this as but a step along the way of reinventing how we interact with and consume media.

- Lytro may not yet have a mobile app, but founder Ren Ng’s new generation of digital camera technology is not just trying to create a cool new consumer device, but rather to redefine an entire industry.

These are but three examples of founders of product companies that are pursuing their passions. Not with the view of turning a quick app that makes some easy money, but rather they set out on this journey well aware that it’s going to take many years of hard work to build out their vision of the future.

Let me contrast this with the six different “startup founders” I met with in just the past few weeks that were all just trying to come up with an app that people liked enough to actually install on their phone. In each case I asked them what they were really trying to achieve with their app and mostly I got confused looks in response.

It’s possible that our industry will evolve to be more like the feature movie industry. Lots of people create apps, a few make it big, and the audience just moves from one blockbuster to another. The casual online games industry is working largely like that now. But even there the best companies are working to create larger ecosystems and not just point games.

If you believe as I do that creating great product companies is a marathon rather than a sprint (albeit a marathon where we’re running 5-minute miles) then to keep the team and your customers motivated for the duration, you need to be pursuing a dream worth getting excited about and staying excited about.

I’ve been using startups as the example here but the same holds true for larger companies. If you’re trying to create major new sources of revenue for your company, you need to have a vision that is compelling to people not just for a few months but for several years. You need to show your team, your execs and your stakeholders that you have a longer-term vision, and you must demonstrate the passion required to get the rest of your company excited.

Getting them excited and keeping them excited is a big part of the product leader’s job, and is known as product evangelism. In an upcoming article I’ll talk about the techniques we have for product evangelism, but they all start with a sincere passion for products that solve real problems.

The Two Core Competencies

Wed, 01 Jun 2011 15:26:00 -0400

Good product teams must be good at product discovery, which means they must get good at learning quickly. They need to be able to zero in on the appropriate target customer, identify the key problems to solve for those customers, and typically the most difficult part of all, apply technology and user experience design to come up with good solutions that will solve those problems.

Our general principle is that we want to learn – test our theories – as fast and cheap as possible. We have two general approaches to doing so: one qualitative and the other quantitative.

User prototyping and user testing:

User prototypes are very quickly created simulations of the product you’re proposing to build.
The main reason we create them is to be able to very quickly put them in front of real target users and customers, generally face-to-face, and test the response.
The big benefits of user prototypes are that they’re quick and easy to create, generally hours or days; they don’t require developer resources to create; and we can get significant qualitative insights into how the product would be used, whether it will address the customer’s problem or need, and whether people would actually choose to use it or not.
A user prototype is not about statistically significant results; it’s about big insights and rapid learning.

For more on user testing, see http://www.svpg.com/the-most-important-thing/.

Live-data prototyping and split testing:

A live-data prototype is real code that’s typically just deployed to a subset of users in some form of an A/B test.
The big advantage of a live-data prototype is that we can gather statistically significant results and prove something actually works or doesn’t work.
Another advantage of a live-data prototype is that we can also test them face to face in a user test just as we do with a user prototype.
The big disadvantage of live-data prototypes is that since it’s real code, it needs to be written by developers and it typically takes days or weeks to create rather than hours.

For more on live-data prototyping and split testing, see http://www.svpg.com/product-discovery-with-live-data-prototypes/.

Because of our general principle that we want to learn as fast and cheap as possible, this generally means a user prototype, however, for many things we simply can’t learn whether something works without live-data, and in those cases we need live-data prototypes.

When trying to decide which technique is most appropriate for the situation, one general rule of thumb is that we can best prove something works with live-data prototypes and split testing, but we can best understand why something doesn’t work, and most importantly, what it would take to make it work, with face-to-face user testing.

But the bottom line is that as a product organization, we need to get good at both forms of learning.

The Most Important Thing

Tue, 10 May 2011 18:31:00 -0400

There are several skills and activities that are important when coming up with great products. In my last article, I argued for the absolute necessity of having good data about how our products are actually being used.

But in the this article I want to argue that the single most important thing product owners can do to add value to their team, their product and their company is a user test.

A user test is when we put the product (or product idea in the form of a prototype – either user prototype or live-data prototype) in front of our target customer and gauge their response.

There are two parts to every user test, and they need to be carried out in this order:

1. Determine if the user can figure out how to use the product.

2. Determine if the user would actually buy, or choose to use, the product, and if not, what it would take to do so.

The first part is a usability test. It is pretty straightforward to do – not hard to do yet the learnings come quick. But consider this the warm-up.

After the usability test, the user now understands what the product is trying to do and how it is intended to help, so you are all primed and ready for the moment of greatest learning, which is the second part: the value test.

Getting users to actually choose to use or buy a product is our ultimate test, and the purpose of the value test is to determine if we’ve met that test. Most of the time we haven’t. But now you’re in a position to learn what you could do to change that.

What makes a product owner useful to his company and team is attending every one of these user tests. To me it is absolutely inconceivable and inexcusable for the product owner to not be at every one of these tests. If at all humanly possible, the lead designer and lead engineer should be at every one of these tests as well.

The product owner typically is there to observe during the usability test (if you have a user researcher they typically drive this portion, and if not, the designer typically drives), but then during the value test the product owner is there to drive the discussion. Don’t leave that user until you have figured out the answer to the question: “what would it take to get this person to actually buy this product?”

The final point I’ll make is that you want to be very open to the pivot. In fact, the fastest and most consistent way I know of to discover potential big-win pivots is through these face-to-face user tests. You may realize you have the wrong target customer or user; you may realize that you’re solving the wrong problem for that user; you may realize you have the wrong monetization strategy; or you may realize you have the wrong approach in your solution.

Mostly we do these user tests using a user prototype, but you can also use your current live product, a live-data prototype, or even a competitor’s live product.

I warn teams that the worst day on the project is usually the first day you actually do user testing. But it gets better quickly. Start by doing at least three user tests a week. Don’t make any really dramatic decisions until you’ve tested on at least a dozen users.

If you haven’t yet done this type of user testing, you are very likely in for some big surprises. But the sooner you jump in, the sooner you’ll learn what you need to do in order to capably steer your product.

Flying Blind

Mon, 02 May 2011 23:08:00 -0400

I know this topic is going to sound far-fetched to many of you, but I am finding too many product teams out there that either aren’t instrumenting their product or site to collect analytics, or they do it at such a minor level that they really don’t know what users are doing on their site or how their product is being used.

My own teams and most teams I work with have been doing this for so long now that it’s hard to imagine not having this information. It’s hard for me to even remember what it was like to have no real idea how the product was used, or what features were really helping the customer versus which ones we thought had to be there just to help close a sale.

Certainly this is easiest to do with cloud-based products and services, and most of us use Web analytics tools like Google Analytics or Omniture SiteCatalyst, but sometimes we use home-grown tools for this.

But good product teams have been doing this for years not just with cloud-based sites but also with installed mobile or desktop applications, on-premise software, hardware and devices that “call home” periodically and send the usage data back to the teams.

A few companies are very conservative and they ask permission before sending the data. But mostly this just happens silently.

We should all be anonymizing the data so there’s nothing personally identifiable in there, but occasionally we see in the news that a company gets in a little trouble for sending raw data in the rush to market.

Sometimes in the press they think we’re tracking this data for nefarious purposes, but we’re simply trying to make the products better – more valuable and more usable – and this has long been one of our most important tools for doing so.

The way this process works overall is that we first ask ourselves what we need to know about how our products are used, then we instrument the product to collect this information (the particular techniques depend on the tool you’re using and what you want to collect), then we generate various forms of online reports to view and interpret this data.

For everything we add, we ensure we have the necessary instrumentation in place to know immediately if it is working as we expect, and if there are significant unintended consequences. Frankly, without that instrumentation I wouldn’t bother to roll out the feature. How would you know if it was working?

For most product owners and designers, the first thing we do in the morning is to check our analytics to see what has happened as of last night. We’re usually running some form of test almost all the time so we’re very interested in what’s happened.

There are of course some extreme environments where everything lives behind very strict firewalls but even then the products can generate periodic usage reports to be reviewed and approved by systems administrators before being forwarded (via electronic or printed reports if necessary) back to the teams.

I’m very big on radically simplifying products, but without knowing what is being used, and how it’s being used, it’s a very painful process to do this when you don’t know what’s actually going on. We don’t have the data to back up our theories or decisions so management (rightfully) balks.

My view is that you just need to start from the position that you simply must have this data, and then work backwards from there on the best way to get it.

Preparing For War

Sun, 24 Apr 2011 21:39:00 -0400

Recently Ben Horowitz posted yet another very thought-provoking article, this time on the different type of leadership that is needed for when things are going along fine (“the peacetime CEO”) versus when things get rough (“the wartime CEO”).

I find this perspective of peacetime versus wartime an interesting way to frame the issue. I realized that most of the time that a company asks me for help, they are usually under attack, they know they need to change, yet they are essentially unarmed.

Startups are born into war. They are fighting for their very survival. Yet larger companies usually achieved their success earlier, and have been riding the growth of their early products for several years.

I used to view these cases mostly as the Innovator’s Dilemma. These were companies that created something great years ago, but now they are struggling to innovate and generate new sources of revenue.

I still think that’s sometimes the case, but in many cases, rather than the company digging in and protecting what they have, it may be more the situation Ben describes – the leaders and culture had been established during the time when the company was thriving; leading in its category and growing consistently for several years. But now there are serious threats to the company’s future, others are stealing their customers, and they know they need to change but they don’t know how.

I often meet companies that have been in peacetime for a long time, and while they weren’t looking, new competitors have emerged, and the methods of doing battle have changed considerably. The enemy has built skills that let him experiment faster and more aggressively, execute faster, and provide better solutions for their customers.

I don’t think the wartime analogy is perfect because it tends to make us focus on competitors, but we’re not really fighting our competitors. If we’re fighting anyone, it’s usually ourselves, especially in larger companies. The real battle is for customers. The companies that win are the ones that consistently innovate on behalf of their customers.

So how do you prepare for war?

Preparing for war means moving to a strong product culture, one where we can learn quickly. Not just minor learnings like we do when we optimize, but fundamental learnings that enable entire new sources of revenue.

It means getting good at product discovery – both qualitative (especially user prototyping and user testing) and quantitative (especially live-data prototypes and split testing).

It means getting serious about user experience design. It means utilizing your best engineers for more than just coding.

Preparing for war also means getting clarity on roles and responsibilities, and raising the bar for everyone in the company. It means abandoning such luxuries as a consensus culture in favor of a truly collaborative culture, with true empowerment but also accountability.

These are some of the fundamentals, but preparing for war mostly means getting serious about the products and services we produce for our customers.

For what it’s worth, my view is that at least in the technology industry, I’m not sure we’ll ever enjoy “peacetime” again. I say that because the industry moves and adapts so quickly now, that I don’t see any leadership position as safe. Staying on top means a relentless focus on customers and continuous innovation.

The Importance Of Failing

Sun, 03 Apr 2011 15:01:00 -0400

Recently a friend of mine sent me a link to this short video from totally outside of the technology field. The video is called “Why You Need to Fail” and it’s by Derek Sivers. Even though the examples are from very different domains, I thought that this short video very eloquently made one of the most important points in creating great products, and I strongly encourage all of you to watch it (especially the second half).

Really. Go watch it and then come back.

I argue with product owners and designers about this all the time. I’m constantly pushing them to just take their ideas and get them in front of users and customers, and to do this quickly – generally much more quickly than they are comfortable with. I’ve written many times about this fundamental concept.

Note that I’m not suggesting they ship what they’ve come up with in only a few days (although sometimes I do), but rather, I know that the real learning starts once you put your ideas in front of real users. And all this time we spend trying to get it just right takes away from the time we have for real learning, and mostly we’re just digging a deeper hole.

There are some people that get hung up on the “fail fast” wording because they think it gives people encouragement to give up fast. When I read this article it was actually April 1 and I thought he was joking, but unfortunately he wasn’t. And this is a smart guy so I don’t doubt him when he says that he has met entrepreneurs that are confused by this. But of course the whole point is that by failing fast we can actually dramatically increase our chances of getting to success.

I personally prefer the language around “learning fast” but when you tell product people they need to fail fast it does help to prepare them to show their ideas early, and understand that it is normal that it takes several attempts before they can expect to have a solution that actually works for the users.

In the UX community we have long had some old-school people out there that didn’t quite buy this, for various lame reasons. So I was very happy to see that Jared Spool recently published a very clear, compelling and what will be for many of his readers a controversial piece acknowledging their findings of where the real learning happens.

If you are on one of the many teams that I work with, you already know that my biggest hot button is when I find that a user test happened and the product owner and designer were not present at the test, or if they were, if they were not allowed to interact directly with the user.

I am hoping that Jared’s article puts the final nail in the coffin for the long obsolete concept of not including product owners or designers at user tests.

There has never been a better time to work on products. The technology, the platforms, techniques from lean startups, customer discovery, product discovery, and agile development are all combining to help a capable product team learn faster than ever, and converge on our ultimate goal which is to create a product we can be proud of and that our customers love.

Developing Strong Product Owners

Thu, 17 Mar 2011 21:40:00 -0400

In my last article I discussed the role of the leader of the product organization. I heard back from more than a few product leaders that it served to remind them that they weren’t doing as much as they knew they should be doing to build the strength of their product team, and I was asked if I could share some of the tools I use to help with this.

I want every product leader to feel considerable urgency and importance around this need. Your company needs the strongest product team possible, and if you don’t develop your team and provide growth opportunities, there are other companies that will. I have always been a big believer in the old adage that “people join a company but leave a manager.”

This note discusses the technique that I use and advocate for providing a framework for ongoing skills assessment and development. I have always called this a development plan, but for some companies that term is used for when you have a problem employee that must improve. While this tool is also useful for that case, I mean for this tool to be used in the very positive sense of helping to develop strong product owners on an ongoing basis, with every employee.

This skills assessment and development plan is structured in the form of a gap analysis. The purpose is to identify areas of development and to make clear the degree to which performance may need improvement along a specific dimension. As such, there are a set of criteria, each with two ratings. The first rating is an assessment of where the employee should be in this skill (i.e. how important it is), and the second rating is an assessment of where the employee currently performs on this scale (i.e. his ability).

Not all skills are equally important, and not all gaps are equally significant, and this mechanism is intended to help focus the attention where it is needed.

Skills Assessment

I have categorized the dimensions into “knowledge,” “process skills,” and “individual skills.” I include a short description of each dimension below but if any of the areas are unclear there are typically articles in the SVPG article archive (see www.svpg.com/articles) covering each.

I have also included my personal view on importance rating for a typical mid-level product owner. However, I encourage each manager to adjust the importance ratings depending on your particular culture, industry, team and product, and also on the level of position (e.g. Senior-level Product Owner has a much higher bar than an Associate-level Product Owner).

On the rating scale, 0 indicates not important (or not strong) and 10 indicates extremely important (or very strong).

Knowledge:

User/Customer Knowledge (10) - Is the product owner the company acknowledge expert on his target users/customer?
Industry/Domain Knowledge (10) - What is the product owner’s knowledge of the industry and domain?
Product Knowledge (10) - What is the level of knowledge of the product owner’s product?
Technology Knowledge (8) - What is the level of knowledge of the underlying technology? How current is his technology knowledge?
User Experience Design Knowledge (7) - How knowledgeable is the product owner on the topics of user experience design? Does he understand the various competencies within UX and does he appreciate and fully utilize this team?
Business and Financial Knowledge (7) - Does the product owner understand the economics and financial dynamics of his product?

Process Skills:

Customer Discovery Process (7) - Customer discovery includes customer interviewing skills, opportunity assessments and understanding of customer development programs.
Product Discovery Process (9) - This is all about getting to minimum viable product. This includes both qualitative techniques including user prototypes and user testing, as well as quantitative techniques including live-data prototypes and split testing.
Product Optimization Process (9) - These are the skills to rapidly improve and refine existing products especially with optimization techniques and A/B testing.
Product Development Process (7) - Does the product owner have a deep understanding of the product development process (e.g. Scrum) and understand his critical role in creating and managing the backlog of work?

Individual Skills:

Team Collaboration Skills (10) - How effectively does the product owner work with the lead developer and the lead designer? Is it a collaborative relationship? Is there mutual respect? Is the product owner involving the lead developer and designer early enough and providing them direct access to customers?
Product Evangelism Skills (9) - How effectively is the product owner sharing the vision for the product and motivating the full product team as well as the various stakeholders and others in the company that must contribute to the product in one way or another?
Time Management Skills (8) - How well does the product owner manage his time? Is he able to ensure he has sufficient time to work on the critically important topics, or is he using most of his time on daily fire fighting? Is he fully utilizing his project manager/ScrumMaster?
Stakeholder Management (7) - How good is the product owner at managing his stakeholders across the company? Do they feel like they have a true partner in product that is genuinely committed to their business success?
Leadership Skills (6) - The product owner does not actually manage anyone, but they do need to lead, influence and motivate people, so leadership skills are important.
Community Management (5) - What is the product owner’s skills in community management and gentle deployment techniques?
Holistic View of Product (5) - Does the product owner strive to maintain a holistic view of product and ensure that the end-to-end experience is strong?

Once you have defined the importance rating for each of these dimensions, you can now assess each product owner as to where they are in terms of each of these dimensions, and therefore identify any gaps.

Development Plan

The skills assessment is just the first part. The second part is to take the areas of the biggest gaps, and then for the manager to identify a set of actions for the product owner to develop his skills in that area. If a skill, such as “Product Discovery Process” is a 9 in importance, yet the person’s current skill level is a 5, then there is a fairly significant gap for a very highly ranked item. As the manager, you can now provide this product owner with training, reading or exercises intended to develop their skills in product discovery.

For the development plan section, try to focus on the top 3 areas. After progressing on these, the employee can move on to the next most important areas.

Also, once an employee has successfully closed the gaps, it is an ideal time to show them how the dimensions and the importance ratings move for the next position (or for other types of positions), and they can set about developing and demonstrating the skills necessary for a promotion.

Be sure to sit down with each product owner no less than once a month to discuss progress on the development plan components and to adjust the skill level. Especially strong people managers discuss this topic weekly.

Finally, you might be wondering how this sort of skills assessment and development plan relates to annual performance reviews. In general, I find the way most companies implement performance reviews to be of little use in terms of developing a strong team. Sadly they are more about compliance and pay administration.

You may have to comply with your HR department’s requirements in terms of annual reviews, but just realize that these are in no way an adequate substitute for active, ongoing, engaged development of each team member’s skills. The good news is that if you are actively managing the skills assessment and the development plan as I’m describing here, then the annual review fire-drill is typically easy.

The VP Product Role

Sat, 05 Mar 2011 18:21:00 -0500

If you take a look at the list of open product positions at the end of my recent newsletter, you’ll notice a record number of VP/Director of Product positions. In part this reflects the growth we are experiencing in our industry. However, it also represents an increased recognition of the importance of strong product leadership.

I work with quite a few different product companies, and I am often asked to recommend and evaluate potential candidates. I have done so much of this lately that it inspired me to write up my views on this product leadership role.

I’ve written this for three audiences:

If you are a CEO or exec recruiter and you are looking for a head of product, this should give you a deeper understanding of what you should be seeking
If you are currently leading a product organization I’d like to offer this up as your keys to success
If you have aspirations of one day leading a product organization, this is a frank discussion of the skills you’ll need to acquire

In this article I use the title “VP Product” to refer to this position, but you’ll also find titles ranging from Director of Product Management to Chief Product Officer. By whatever title, I am referring here to your most senior product role in your company or business unit.

Organizationally, this role typically manages the product owners/product managers and the user experience designers, and generally reports to the CEO. With some exceptions, it it is important that this role be a peer to the CTO and the VP Marketing.

I’ll say right up front that this is a difficult role to fill and to perform well. Those that do succeed make a dramatic difference for their companies. Great product leaders are highly valued and often go on to found their own companies. In fact, some of the best VC’s only invest in founders that have already proven themselves as great product leaders.

Competencies

Specifically, you are looking for someone that is proven strong in four key competencies: Team Development, Product Vision, Execution, and Product Culture.

- Team Development

The single most important responsibility of any VP Product is to develop a strong team of product owners and designers. This means making recruiting, training and ongoing coaching the top priority. Realize that developing great people requires a different set of skills than developing great products, which is why many otherwise excellent product owners and designers never progress to leading teams.

And one of the worst things you can do is take one of your poor performing people and promote them to this leadership position. I know that may sound obvious, but you’d be surprised how many execs reason that, “well, this guy is not very strong, but he works well with people and the stakeholders seem to like him, so maybe I’ll make him the head of product and hire a strong individual contributor person to backfill him.” But how do you expect this poor performer to help develop his team into strong performers? And what message does this send to the organization?

For this position, you need to ensure you are hiring someone that has proven the ability to develop others. They should have a track record of identifying and recruiting potential talent, and then working actively and continuously with those people to address their weaknesses and exploit their strengths.

- Product Vision

Product vision refers to defining and driving the product strategy. The vision is what drives and inspires the company, and sustains the company through the ups and downs. This may sound straightforward but it gets tricky. That’s because there are two very different types of product leaders needed for two very different situations:

where there is a CEO or founder that is the clear product visionary
where there is no clear product visionary, usually in situations where the founder has moved on

There are two very bad situations:

The first is when you have a CEO that is very strong at product and vision, but he feels that he wants to hire a VP Product (or more often his board pushes him to hire a VP Product), and he thinks he should be hiring someone in his own image, or at least like him in that he’s also very visionary. The result here is typically an immediate clash and usually a short tenure for the VP Product. If this position looks like a revolving door, it’s very possible that’s what’s going on.

The second bad situation is when the CEO is not strong at vision, but he also hires someone in his own image. This doesn’t result in the clash (they often get along great), but it does leave a serious void in terms of vision and this causes frustration among the product team, poor morale across the company, and usually a lack of innovation.

The key here is that the VP Product needs to complement the CEO. If you have a strong visionary CEO, there may be some very strong VP Product candidates that won’t want the position because they know that in this company, their job is primarily to execute the vision of the CEO.

One situation that unfortunately happens is when you have a visionary CEO and he has a solid partner running product that is very strong at execution, but the founder eventually leaves and now the company has a problem because nobody is there to provide the vision for the future. It’s generally not something a VP Product can easily turn on and off, and even if they can, the rest of the company may not be willing to consider the product leader in this new light. This is why I generally prefer when the founders stay on at the company, even if they decide they want to bring in someone else as the CEO.

If you’re wondering what to do when you have a CEO that thinks he’s a strong visionary leader, but the rest of the company knows he’s not, you need a very special head of product, one that is a strong visionary, but also has the ability and willingness to convince the CEO the vision was all his idea.

- Execution

No matter where the vision comes from, all the great vision in the world doesn’t mean much if you can’t get the product idea from concept to live to site. You need a product leader that knows how to get things done and has absolutely proven his ability to do so.

There are many aspects that contribute to a team’s ability to execute consistently, rapidly, and effectively. The person certainly should be expert on modern forms of product planning, customer discovery, product discovery, and product development process, but execution also means that they know how to work effectively as part of your size organization.

The bigger the organization, the more critical that the person has proven strong skills especially in stakeholder management and internal evangelism. The product leader must be able to inspire and motivate the company and get everyone moving in the same direction.

- Product Culture

Good product organizations have a strong team, a solid vision and can consistently execute. A great product organization adds the dimension of a strong product culture.

A strong product culture means that the team understands the importance of continuous and rapid testing and learning. They understand that they need to make mistakes in order to learn, but they need to make them quickly and mitigate the risks. They understand the need for continuous innovation. They know that great products are the result of true collaboration. They respect and value their designers and engineers. They understand the power of a motivated product team.

A strong VP Product will understand the importance of a strong product culture, and will be able to give real examples of his own experiences with product culture and have concrete plans for instilling this culture in your company.

Experience

The amount of relevant experience, such as domain experience, will depend on your particular company and industry, but at a minimum, you are looking for someone with the combination of a strong technology background with an understanding of the economics and dynamics of your business and your market.

There is a debate going on right now in our industry about the value of an MBA for product leaders. All of us inside the industry can’t help but be biased because we either do or don’t have one (I don’t). I think I know as many product leaders as just about anyone in this industry, and I know many very strong leaders both with and without. I absolutely do not consider an MBA a requirement, but I personally would not avoid hiring someone just because they had an MBA, as long as they convinced me that they had the right mindset per the above.

Chemistry

Last but certainly not least, everything discussed above is still not enough. There is one more thing. Your product leader must be able to work well on a personal level with the other key execs, especially the CEO and CTO. It will not be fun for any of you if there isn’t that personal connection. Make sure the interview process includes a long dinner with at least the CEO and CTO. Be open and make it personal.

Why Traditional Messaging Fails

Mon, 28 Feb 2011 13:20:00 -0500

Back when I was a product manager for Microsoft Office, we spent hundreds of thousands on positioning research. Messaging lived for years on store shelves, so getting it “right” was important. We thought about every word and enforced consistency, summarily dismissing changes from well-intentioned copywriters.

Today, that messaging would fail.

Why? Because unless you have an eight-figure marketing budget, you must assume the first place people hear about your product is from someone someplace beyond your control.

Messaging’s job today is to engage at least as much as inform. This requires much more concrete, bite-sized messaging that can easily be understood and conveyed by others. Facts, stories, enthusiastic quotes, ratings, explanations—not just benefits—are all essential parts of messaging because they are more authentic than claims.

The three most common problems I see in messaging are:

“We’re new so people care” or “Let-me-tell-you-what-I-want-to-tell-you”. As technologists, we believe what we’ve created is great and that people care about something new and cool. At the end of the day, what people care about most is “I love it. It solved my problems. It was great.” Features and even cost become much less of a factor when you have other people as fans for proof. And no, I don’t mean case studies.

Not tailoring messaging to customer lifecycle. All customers have a life cycle that provide different opportunities to message around acquisition, activation, retention, referral and revenue. What’s good for one often differs than what’s good for another. Too often messaging is built around just one of those areas (usually acquisition) instead of being specific to the desired behavior along another point in the customer’s lifecycle. Split-testing has made this level of messaging specificity easier.

Not adapting messaging to audience and adoption-curve. Beyond the customer lifecycle, early adopters need different messaging than mainstream consumers. This is perhaps the biggest reason why messaging must be much more varied than ‘traditional’ marketing allows. Leave consistency for brand and positioning—messaging must adapt to where a product is on its adoption curve and what a particular audience needs to hear at a given point-in-time.

As you examine your messaging, here are a few basics to think about (caveat – design and presentation matter a lot which I won’t address here):

Clarity over comprehensiveness. By ‘traditional’ messaging standards, this 37Signals example looks pretty good: “Pay as you go. No long term contracts. No hidden fees. No surprises.” Lots of information in short, easy to read, rhythmic sentences. Yet the simple, clear articulation of what to expect outperformed it: “Sign-up takes less than 60 seconds. Pick a plan to get started!” Don’t overload your messaging. Keep people focused on just what they need to hear to move through that one point of conversion.

Authentic over authoritative. Studies proved the most easily scanable yet comprehended text is a short sentence followed by bullets. So most websites default to messaging in that format. But it has a dramatic effect on tone, that in today’s world, doesn’t differentiate or help with engagement. Take a look at Expedia vs. Kayak:

“Why it pays to book with Expedia:

Huge savings on Flight + Hotel vacations
No Expedia booking fees on flights
More hotels (and more deals!) in more place”

Yawn. I’m bored and probably skipped it entirely. Sounds like and looks like everyone else. Here’s Kayak’s more conversational approach:

“We’re Completely, Entirely,…Totally Different.

With Kayak, you can compare hundreds of travel sites at once (that’s right, you don’t have to search 20 travel sites anymore)….oh, and Kayak is free to use.”

Kayak’s approach engages and communicates a lot about the brand. If you bothered to read it, you probably actually processed what makes them different.

Evidence-based messaging. Different people need to hear different things to take action, but facts vs. claims are always more powerful. Mint.com does a great job of providing lots of evidence directly on their Home Page for why someone should try them: social proof, endorsements from major media, video showing the product in action (vs. just telling you what it does), a pain-point they can solve (tax time) and how they manage security. Although social proof has a lot of attention these days, the larger point is you need to show proof--not just make claims--and there are many kinds. Don’t force users to look hard for evidence that you are worthy of their attention.

Test everything. With site analytics and split testing, the answer to what’s the best messaging should always be, “Let’s see.” Don’t try to follow a formula. What works best for one service is not necessarily the best messaging for you. Remember, the context someone sees before finally finding your ‘official’ messaging will always be different.

For example, which of the following do you think converted better?

(A) “Get Free Email Updates: Join 14,752 others!” or

(B) “Get Email Updates (it’s Free)”

Answer: For that site, (B) the version WITHOUT social proof outperformed those with it by over 100%! This isn’t the result most would have predicted, given today’s huge push toward social proof. But for that site, the design and presentation of social proof didn’t help. Make no assumptions. Test and trial everything. (for complete analysis: http://diythemes.com/thesis/increase-conversions-split-testing/)

I hope this gives you a new lens through which to look at your messaging. Remember: engage your customers with what THEY want to hear and test EVERYTHING. It’s the path to more authentic messaging that moves toward conversion…messaging’s ultimate job.

Product Discovery With Live-Data Prototypes

Sun, 20 Feb 2011 06:19:00 -0500

In my last article I discussed the keys to product optimization including A/B testing. However, I emphasized that this type of A/B testing is not the same as the A/B testing we do during product discovery. In this article I’d like to talk more about how we utilize live-data prototypes and A/B testing to facilitate product discovery.

The principle objective in product discovery is to discover the smallest possible product that is valuable, usable and feasible, and to do this as fast as possible. This means failing fast. Trying our ideas out on real users and customers, learning and adjusting, and pivoting if necessary. We know we’ll need several iterations to get to where the product actually works for us, so we want to work through those iterations as fast as we can.

We have two primary techniques for failing fast:

- The first is to create a user prototype (disposable software that is meant to simulate what the real software would look like and behave like) and then test that prototype on real users and customers (mostly face-to-face with users from the target market).

- The second is to quickly create real code to test an idea with live data (we call that a “live-data prototype”) and then test this software by running a percentage of our traffic to this new version and compare the results (called an A/B test or split test).

These techniques are not mutually exclusive (you can find both of these techniques used at most of the best tech product companies), but the general principle is to test the hypothesis the fastest and cheapest way possible.

Often that means a user prototype with user testing. We can usually do that in days. The learning is qualitative rather than quantitative, but the insights are usually dramatic. See Beyond Usability.

However, as valuable as user prototypes and user testing may be, often you need live data in order to determine if an idea actually works.

Some of my favorite examples of this are when applying game dynamics to e-commerce, search result relevance, many social features, and of course funnel work.

To be clear, creating a live-data prototype is essentially coding. So this means you’re going to need access to developers to create the prototype. At a typical early stage startup, this is usually not a big problem. After all, there is not usually a legacy system to keep running with a long backlog to work through. Unfortunately, at more established companies, it can be hard to get sufficient time from the developers to build and deploy a live-data prototype.

The live-data prototype is typically substantially smaller than the eventual product. For example, the bar is typically lower in terms of quality, performance and functionality. It needs to run enough to get validated learning, but typically there is more work to be done before you’d roll it out widely. A good example would be internationalization and localization work. You can usually test your idea in a single geography with a single language and payment system, and if things go well, you can do the additional engineering needed for a wide-scale rollout.

One of the advantages of user prototypes is that they are usually created by the designers so the dependency on actual developer time is limited to their time to review each prototype iteration for both feasibility and also to contribute ideas and insights.

Another disadvantage is that building a live-data prototype can take more time than a user prototype. However, the stack that developers have to build on is getting better all the time, and there are technologies and frameworks that can make even a one or two developer team extremely productive, in the best cases reducing cycles down to a few days. Note that you do need to be extra careful not to fall into the trap of taking too long to get the idea in front of real users and falling in love.

That said, there are important advantages to live-data prototypes. The data generated is unrivaled for learning how the product idea performs in the wild. And of course, if the test does go well, you are well on your way to deploying the software for real.

So far we’ve been talking mostly about the startup context. In the case of a startup, it’s usually not very hard to convince the leaders and investors of the need for product discovery. They understand that it’s essentially a race against the clock (until the money runs out) to see if you can come up with something that could fuel a business.

However, in the case of a more established company, you typically already have products that are fueling the business, so the reasons for discovery are a little more subtle.

At established companies, product discovery, with both user and live-data prototypes, is about reducing the risk and cost of innovation. Reducing risk in case the idea doesn’t actually work, or in case it might hurt the brand, or in case it might cannibalize existing business. Reducing cost because building, deploying, and supporting is expensive in time and money.

Without effective ways to reduce this risk and cost, many organizations consider the risk as not worth the possibility of a reward (If the reward were a sure thing, more might take the risk, but given that it’s not a sure thing, the risk and time make the necessary experiments expensive and unlikely.)

So whether with user prototypes or live-data prototypes, our goal in enabling product discovery is to dramatically reduce the time, costs and risk necessary for rapid experimentation and failing fast.

Notes on Split Testing:

- As I mentioned in the previous article, there are many tools out today to enable A/B testing, however they are typically appropriate for the optimization work and not usually for the type of testing we do in product discovery. This is because the ideas we are testing are typically not incremental changes to surface level pages, but substantially different from the front to the back. Fortunately, enabling an A/B test during product discovery is not really that hard. This Eric Ries article does a good job describing a useful approach.

- Yet another use of Split Testing is as a gentle deployment mechanism.