svpg blog

Product Discovery for Non-Technology Products

Fri, 05 Mar 2010 08:27:00 -0500

Article: Product Discovery for Non-Technology Products

I’m often asked whether or not the concepts that I advocate and write about are applicable to non-software products as well as the consumer and business internet services that I almost exclusively focus on. My answer has always been that I really didn’t know because in my career I have only built software technology products.

However, there is one exception. When I began the process of writing a book, I wanted to apply as many of the concepts I advocate as possible, not just to see how well they worked, but also because I felt I genuinely needed them to help me come up with something of value.

The book has been out now for over a year, and there are more than 40 reviews on Amazon, nearly all 5 star, and sales have continued to grow steadily far beyond what I had a right to hope for. So now I finally have some confidence that the techniques truly can help with non-technology products as well. In this note I thought I would highlight the learnings from this project.

Many management consultants write books as a form of brochure for their services, but I wanted this to be something for the people that could never afford to work with me directly, or in corners of the globe I am unlikely to visit, and also to have something that persists. So to me it was important that the book provide real value. Here are the main product discovery techniques that I used to come up with the book:

First, I needed to discover which concepts were unique to the companies and teams I had happened to work for, and which concepts applied more universally. Fortunately my profession provides me access to a large number of leading technology teams, so I was able to visit a range of customers to learn in depth about the challenges they face. So effectively I was doing user research and product discovery from the very start.

Second, I identified a set of six product leaders that were what I considered representative of precisely the target audience I wanted to reach, and I asked them if they’d be willing to serve as my “charter customers” (I didn’t actually call it that – I asked them if they would be willing to help me with this book by answer ongoing questions, and provide detailed review of the drafts). But the point is that I really did try hard to get the book to the point where at least this handful of people found true value.

Third, I used my blog to post articles about specific topics, and then I used the feedback, mostly site analytics, comments and follow-up questions, to gauge which topics were most relevant and helpful, and to address the questions pro-actively by improving the content.

Fourth, I created a high-fidelity prototype of the full book by weaving the individual topics together into the whole, and also looking at the form factor including title, cover design, and interior design. Using digital printing technology I created a prototype of what I hoped to be the final product. Just like with software, I was amazed at how much I discovered once the book was in this realistic form factor. Even something as basic as the page size (the aspect ratio in particular) looked great online, but clearly looked wrong once we did the prototype.

Fifth, I sent this prototype to an expanded set of reviewers as well as to several hundred attendees of a conference that I considered representative of the target market. This was my form of beta release, and many problems which had gone undetected until then were caught and corrected. One consequence of the feedback was the decision to produce the book in hardback rather than soft cover.

At this point, I believed I had real evidence that the book would serve its purpose and provide real value. The prototype also enabled me to get accurate manufacturing costs. Only then was the book sent to production.

Hopefully the above doesn’t sound easy – the full process took nearly three years (although the first two years were really figuring out which topics I wanted to write about). There were several people that helped with important elements of the book. I had a good editor, a terrific designer for cover and interior design, and a great company that had strong experience with printing and production. Anyone that would like introductions to any of them just drop me a note.

But I do think the principles of product discovery, having deep and ongoing access to target users/readers through the charter customers, and the use of prototypes and product optimization techniques, all were essential to the success of the book.

It is interesting to contrast the process I used with the conventional publishing process, which I would argue is essentially waterfall. Authors and publishers of course create drafts and get feedback, but usually by other writers or editors and not by the target readers. Publishers sometimes create multiple versions of covers, but this is to get the feedback of their sales and marketing people. Publishers also occasionally produce an “advanced reader copy” prior to the main production runs, but that is for getting reviews before publication rather than broad beta testing.

But my purpose here is not to try to advocate for changes to the publishing process and industry. That is already happening. The Internet has made it dramatically easier to build a community, get near real-time feedback of your ideas, and to publish directly and inexpensively – especially digitally. Rather, I wanted to explore the applicability of the techniques our technology industry depends on to non-technology products.

If you are working on a non-technology product and have tried applying any of these techniques, please drop me a note and let me know your experiences.

A special thanks to my long-time friend Mark Coggins, a senior technology executive as well as the author of a successful series of crime fiction novels (all based in the Bay Area and with a tech industry backdrop). You should check out his work at http://www.markcoggins.com.

Dedicated Product Teams

Thu, 18 Feb 2010 13:28:00 -0500

In my last article I talked about the importance of knocking down walls, especially the wall between product management and engineering. In this article, I want to describe a technique that helps achieve this, along with several other significant benefits.

While there are many variations, there are essentially two common ways of running your product organization. The most common of the two is to do some form of project-based planning. In this model, the management of the company essentially defines a communal roadmap – they come up with a prioritized set of projects for the quarter or year, and they allocate time and people to those projects. For example, they may have a team spend two months working on a new advertising system, and then the next high-priority project for that team might be a new search technology, or some SEO work. The team may or may not change, but the project and even domain they are working on typically changes frequently.

Basically if you look at the communal roadmap, you see a mosaic of different projects, each row typically an allocation of a set of developers to a project.

These roadmaps hardly go a week without significant change. Some new business opportunity comes in and takes priority, so that throws a big wrench in the plans and a bunch of shuffling is done, or a project takes longer than expected, so that has a ripple effect.

(Not to mention that these project-oriented portfolio roadmaps are typically created before there is any real information or knowledge on what it will really cost to build this, and whether customers will actually want to use it. But that’s a different issue.

These communal roadmaps change so frequently are are so full of assumptions that they’re rarely something companies enjoy, but nevertheless this is often how they run their product organizations. There are, however, several less obvious consequences of this approach.

First, teams are constantly moving around. Product managers team up with specific developers on a project basis. Often they don’t have nearly the time they need to form the working relationships so important to effective teams.

Second, the developers are often constantly reassigned to different areas. While on the positive side the developer gets exposed to lots of different areas, they often don’t get the time to develop the deep expertise in an area that can make a developer so incredibly valuable.

Third, since the developer is switching topics so frequently, they don’t develop the velocity that an experienced team does.

Fourth, since the developers are scheduled on different projects beginning right after the prior project ends, this tends to encourage what we call “release and forget” where a project is launched because it is scheduled to launch, but the follow-on work and the product optimization work gets deferred for months or even indefinitely because the team is on to other projects.

The alternative to this, which I’m happy to say is spreading fairly rapidly across our industry, is to move to dedicated product teams.

In this model, the executives, rather than debating specific projects, instead consider which areas of the business they want to invest in, and what percentage of resources to allocate to each area. For example, for a typical e-commerce company, they might have teams like “Search and Recommendations,” “Product Pages and SEO,” “Fulfillment Systems,” “Infrastructure,” “Rapid Response” and “New Business Opportunities.” They would then choose what level of investment they consider appropriate for each area.

The next step for the management team in this model is to define Product Team Scorecards for each of the teams. This essentially sets the business priorities for each of the teams.

Next the organization staffs the teams with a product manager, user experience, developers, and QA, in proportion to the allocation decided above.

In this model, the team then is charged with coming up with the projects, features and fixes that they believe will best deliver on the KPI’s defined in the Scorecard.

There are two important differences here. The first is that these teams are ongoing. They don’t switch from topic area to topic area after every project. Instead, they focus their energies on building true expertise on their topic, and coming up with real innovations in their areas. The second is that the team members are persistent, in that they are assigned to this product area and they’re not just here for the specific project.

Of course management may choose to adjust the balance of resources by reallocating people, or by adjusting the Scorecard to reflect changing business priorities – this usually happens quarterly or annually. And of course people are not sentenced to work on this area for the rest of their career. They can and should move between teams, but generally people are working on a team for a year or so, and not just for a few weeks or months.

As I watch companies switch to this model, I consistently see the velocity go up as the teams gain expertise. I also see the quality of product go up dramatically which I attribute both to the relationships that are built and also to the sense of ownership that teams feel over their area. But most importantly, I see the business results that stem from the focus, the better product work, and from continuous and rapid improvement of the product.

A few notes:

- A very useful dedicated product team is the “rapid response team,” there to handle critical fixes and relatively minor improvements and functionality. I’ll describe this in more detail in an upcoming article.

- I also like a “new business opportunities team” that is there to explore new potential products or sources of revenue. In most companies, these opportunities will always arise, and if you don’t have a team available to pursue, then all too often other teams are raided for resources. Instead, plan for a small team to pursue these opportunities, and help them get good at evaluating potential.

- The one team and allocation that’s usually a given is the “infrastructure team.” This is a special team, usually comprised of just engineers and architects, and the allocation is typically 20% for consumer internet companies. You can instead intersperse this work into the other teams, or you can have a blend (a dedicated team plus some resources in each of the other teams).

- Moving to Scrum, if you haven’t already, will get you part-way towards dedicated product teams. It helps a great deal in building the personal relationships of an effective team. But all too often, Scrum teams are still handling backlog items from many product areas, and not being given the ability to focus on an area as a team. That’s the difference really between a project team and a dedicated product team.

While I typically recommend moving to dedicated product teams for the full product organization, be warned that this is not a trivial change and requires executive support. If your organization is not yet convinced, you can move just one or two teams to the dedicated product team model. If you give this model even 6 months I’m fairly certain you’ll see the benefits and hopefully make the switch at the next planning cycle.

Knocking Down Walls

Tue, 09 Feb 2010 13:30:00 -0500

One of the great things about startups is that they are so small that there’s almost no organizational structure to speak of. Basically everyone there is just trying to create something people want.

But as organizations grow, people start spending more of their time managing people and process rather than creating, and pretty soon you start specializing into typical functions of technology, product and marketing.

Unfortunately, a consequence of this organization is that often walls emerge between these groups. People often feel a closer affinity or allegiance to their group than they do to their actual product team they work on. Just take a look at who the people go to lunch with, or who they grab a beer with after work. If product managers generally hang out with other product managers, that’s a sign of the wall.

When the product managers and the developers aren’t on the same page, or they don’t understand what the other is trying to do, that’s a sign of the wall.

One of the things I like about Scrum is that it does quite a bit to break down these walls. But even with Scrum teams, sometimes the product manager isn’t the actual product owner, or he may technically be the product owner, but he’s not really engaged with his team.

There are other walls as well, such as between product and marketing, or between product and user experience, but the worst wall of all I would argue is between product and technology. It is almost impossible to accomplish something good when the development team and the product manager do not have an effective working relationship.

And to me an effective working relationship is based on a personal relationship.

Product discovery is the result of a true collaboration between product, user experience and technology, and that true collaboration depends on these relationships.

The simple act of moving the desk of the product manager to be next to the desks of the developers can have a dramatic impact. Soon they start going to lunch together, and playing foosball together, and finally sharing ideas together.

I’ve written earlier that teams that use their developers just for writing software are only getting about half the value out of their developers. If you want to get to that other half, it starts by building these relationships.

In my next article I’ll discuss another technique for knocking down these walls, as well as addressing several other common problems.

Regaining Your Product Mojo

Tue, 26 Jan 2010 11:59:00 -0500

In my last article, I talked about the problem where your product organization has been relegated to the role of a service organization, largely documenting the decisions and desires of others. I must have struck a chord because I received a record number of comments, mostly from people that felt trapped in this very situation and were anxious to see if there’s hope for change.

In this article I want to share some of what I’ve learned in helping organizations to “regain their product mojo.” Here are ten specific suggestions:

1. Demonstrate Customer Expertise.   As I mentioned in the previous article, everything starts by reconnecting with your customers. And I’m not talking lip service. You will know you’ve accomplished what you need to here when the product organization, and especially each product manager in that organization, is acknowledged across the company as the undisputed expert in your customers.

2. Create a Rapid Response Team. This might sound tactical, but you can’t just say no to all the day-to-day operations of the business while you rush out to meet your customers, and do the rest of the items below. As a product organization, you need a way to respond quickly to the pressing needs of the business, but without taking down your whole team. My favorite technique for this is to establish a dedicated “rapid response team.” This is usually a small team (a product manager, 2-3 engineers and a QA person would be typical) but they are there to jump on the urgent issues that invariably come up all the time – the ad sales guys bring in a new partner that needs something a little different; serious bugs that are discovered and must be fixed; marketing needs support for a new promotion; you get the idea. The members of this team typically rotate out every 3-6 months or so, and it’s also worth noting that they often do frequent release cycles such as weekly. But just having even a small dedicated team can substantially improve the organization’s responsiveness to the needs of the business and the customers, while providing some air cover to the rest of the organization.

3. Embrace User Experience Design. If you want to create strong products, especially consumer Internet products, you’re going to have to get serious about user experience design. You need designers that can provide you with strong designs that work, and you need the people and processes to get the evidence you need to make your case (see “data not opinions” below).

4. Design In Customer Acquisition. Especially for those of you doing consumer Internet products, you simply must worry about customer acquisition from the start. It used to be that we said that the product team did the product, and marketing was responsible for customer acquisition. Not anymore. Customer acquisition is too critical, too expensive, and too integrated into the product (or needs to be) to be left completely to others. You’ll need to reach out to your marketing colleagues and pull them into the product process, and you’ll need to factor in customer acquisition considerations into all of your product and design work.

5. Collaborate With Developers. If you want to create great products, you simply can’t afford to ignore your engineering colleagues. In far too many organizations, there’s a big wall between the product managers and the developers.   These organizations are at a severe disadvantage. Starting on day 1 of a project, you need to include both your designers and your lead developers. Do whatever you have to do to ensure they are engaged and participating.

6. Mitigate Risks. One of the biggest reasons that companies cease to innovate is that they are scared. They’re scared of putting existing revenue at risk, or of damaging their brand, or of angering partners or customers. A strong product organization must be good at mitigating these risks. We do this with prototypes and user testing (to fail fast), and with split testing and product optimization (to improve fast) and both of these techniques are not exposed to the broad customer audience until we have the data we need.

7. Think Big. You simply aren’t going to make a big difference for your company by just coming up with a bunch of random features. Your company and your customers are looking to you for thought leadership. They want you to paint a picture of the future and give them the confidence that it’s achievable. Create a product strategy and communicate it with a visiontype.

8. Data Not Opinions. When you’re working to build credibility in your organization, and trying to convince the company to be more aggressive and take more risks, you need to stop trying to convince by your words, and start bringing data.   And with company executives, the data that matters most comes straight from the mouths and actions of customers. If you run into your CEO next week and tell him about the 7 customers you met with this week and what you learned, that will make an impact, especially if it’s on top of your learnings from dozens of others in the weeks prior. User testing and split testing are both good techniques for quickly collecting this data.

9. involve Company Executives. Your goal is not to get your company executives to leave you alone. Your goal is to change the nature of the interaction. You want to engage with your executives at least every week, sharing what you’ve learned last week, and what you are planning to test next week. They don’t expect that all your ideas will be home runs. But they do expect that you will be improving quickly, mitigating the risk of experimentation, and that you’ll be learning from your successes as well as your failures.

10. Evangelize. Finally, it’s not enough to just do good work. Especially in larger organizations, you have to evangelize. You have to make sure others around the company understand what you’re doing, what you’re learning, why it’s important, and how they can help. You can’t be shy. The company is betting in large part on you. They need to know you and understand what you’re trying to accomplish and why it’s important. Good executives are not just betting on a market opportunity, they are betting on you.

Several of these topics warrant their own article, but hopefully this list will give you a sense of what you’ll need to do in order to reestablish your product organization as the thought leaders and customer champions that your company needs you to be. Let me know how it goes.

Product Management as a Service Organization

Wed, 13 Jan 2010 14:32:00 -0500

Probably one of the most common complaints I get from CEO's of mid- to large-sized companies is the lack of innovation and thought leadership from their product organization. They see the money they spend on product managers, designers, engineers and QA, yet they often see only marginal improvements to the business. Yet in most of these organizations, when I look at their roadmaps (these organizations rarely have product strategies), they’re littered with literally hundreds of specific features and incremental enhancements.

When a company is just starting out, it’s all about finding something that resonates with users and delivering real value to customers. It’s why startups are such great places for innovation. But for those skilled or fortunate enough to accomplish that, as the company starts to grow, very often the nature of the product organization changes into a group whose main purpose is to serve the needs of the many stakeholders across the business – business owners, sales, marketing, business development, legal, finance, operations, customer service, etc.

The job of the product manager then devolves into one of documenting stakeholder requirements, mediating conflicting objectives, and allocating the limited developer resources to try to satisfy as many of the stakeholders as possible.

Is it really any surprise that innovation stops? Is it really a surprise when your most talented and creative people leave for another startup, while the ones that remain are willing to spend their days running from stakeholder to stakeholder trying to negotiate some kind of agreement?

Now, of course there are always very legitimate business requirements that have to be addressed and accommodated. Supporting contractual obligations, monetization opportunities, and addressing operational issues are all very real examples.

However, many product organizations become so overwhelmed with these urgent day-to-day stakeholder obligations that two even more important responsibilities are pushed aside. The first is the focus on the actual customers and their needs; and the second is the future of the company and what it takes to provide sustained differentiation and ongoing sources of revenue and value.

Strong product organizations work to strike a balance between those things required to keep the business operating, and innovating on behalf of the customer.

Product organizations must achieve this balance otherwise they cease to provide the role that is needed. In some companies, especially those with strong business owners or strong senior executives, others will feel they need to step in and try to fill this void, and it’s hard to fault them for that.

After years in this situation, the problem becomes cultural and institutionalized, and the product organization is not empowered, rarely even respected, and of course they are frustrated.

Fortunately, this situation can be corrected although it’s not a simple change, and it requires sustained and strong leadership.

It starts by having the product organization earn the respect of the company and its leaders, and this won’t happen until the product managers become the recognized expert on the company’s customers and users. And this of course means reconnecting with your customers in a big way.

Once you’ve done this, and leaders from across the company seek you out because of your understanding of the customer, then you’ve earned that seat at the table, and now you can bring the opportunities that you have discovered during your intense customer interactions.

I don’t mean to oversimplify what it takes for a product organization to regain its mojo; I’ve got another article brewing on a set of steps to achieve that, but for those of you that feel trapped in a product organization that lives to serve the company stakeholders rather than your customers, and I know there are many of you, I hope you will take a look at your roadmaps and backlogs and ask yourself which of those items are actually serving the customer and have a chance at delivering real value for your company?

The Product Decade

Mon, 28 Dec 2009 13:54:00 -0500

I don’t think there has ever been a better time to be a product person than right now. In fact, I’m fully expecting the decade about to begin to be far and away the most productive in terms of innovation.

There are several reasons for this:

First, the devices – especially mobile, where we now have a critical mass of people all around the world with a device that is continuously connected to the Internet, location aware, and fits in your pocket. I’m also very optimistic about the tablet as enabling an entirely new class of applications.

Second, the platforms – especially from Apple, Facebook, Amazon, and Salesforce.com, among others – enable a degree of power and reach beyond anything we’ve ever seen. A good Facebook or iPhone application can quickly find itself with millions of users.

Third, the up-front costs – the barriers to trying out an idea have never been lower. If you have an idea for a product or service, it used to take substantial amounts of money and time to get your idea in front of users and customers. But no longer. With great tools and platforms, and ready access to skilled talent around the world via services like Elance, we can take an idea from inspiration to live prototype for about the price of a nice vacation. (And I fully expect many people will do just that – they’ll trade out their vacation to pursue a startup idea on the side). One consequence of this is that I expect the VC’s to play a different role in the startup ecosystem going forward. They’ll be valued more for their expertise and introductions than their money.

Finally, the techniques – over the past few years we’ve been working out the tools and techniques for rapidly exploring and testing ideas, discovering pivots, and optimizing design. The result is that we can prove out an idea (one way or the other), or help an idea reach its potential, faster than ever before.

I still expect startups to be the primary environment for innovation, but I am optimistic about the state of innovation inside large companies as well. Don’t get me wrong, I fully expect to see many large companies get knocked from their pedestals because they dig in their heels, resist the changes in the industry and spend their energies trying to protect what they have. This has always been the case, and I expect it always will be.

However, for those companies that embrace the opportunities that the changes bring, then we now have better techniques than ever for mitigating the risks to current business. We can explore new ideas less expensively, and we can incorporate new approaches without putting existing revenue at risk.

I am grateful for the front-row seat that so many innovative companies have provided me as they push the envelope. I have never been more excited about the future of product and innovation as I am now, and I hope you are too.

No Silver Bullet

Mon, 30 Nov 2009 19:13:00 -0500

More than 20 years ago Fred Brooks published a seminal essay on the nature of software, called “No Silver Bullet: Essence and Accidents of Software Engineering”. If you’ve never read it I’d highly encourage it, as even though it’s ancient by the standards of our industry, it’s still amazingly relevant and gets to the heart of why creating great software is so hard.

I thought of this article again recently, as one thing that truly frustrates me is that there are always people out there in software arguing that their favorite technique is essentially a silver bullet, and all you need for great results is to follow their favorite practice. Reminds me of the old saying that if the only tool you have is a hammer, then every problem looks like a nail.

For some reason, the software process world has always seemed to attract more than its share of these zealots. I hope I never become one of those people.

I am a big fan of Scrum and aggressively advocate its use, but sadly there are many core problems it simply doesn’t address.

Similarly, I’m a huge fan of web analytics and split testing to optimize products, yet there are critical insights about your users you’ll never learn if this is your only technique.

I also love to use the combination of high-fidelity prototypes and user testing, yet I would never argue that this is all you need to do.

Same with personas, contextual inquiries, product principles, charter customer programs, and dozens of other valuable techniques.

Instead I believe that a strong product leader needs to be armed with a range of tools and techniques to be employed where appropriate.

I’m sorry if this sounds harder than just learning a single tool or technique, but not only will you create better products, but you’ll find that you are better equipped to deal with whatever product challenges you’re faced with.

Outsourcing Core Competencies

Fri, 13 Nov 2009 13:10:00 -0500

I work exclusively with commercial software product organizations. Organizations that must create products and services that thousands or millions of users must make an independent decision to use or buy. This is in contrast to custom software companies that create software purely for internal use. But since many companies have moved from custom to product software I often find companies with behaviors and practices inherited from their prior life as a custom software company, but one practice that really deeply bothers me is when I find a product organization that is outsourcing core competencies.

Don’t get me wrong, there are many things that can be effectively outsourced no problem. I’m fine with using outside firms for supplementing QA, or for getting help with SEM or SEO, or for managing events, or for dozens of other activities which are not really core competencies of the organization. But there are three things that I consider absolutely essential to build capabilities in-house if you are trying to become a world-class software product organization:

- Product Definition
- User Experience Design
- Site Architecture

Unfortunately, I have seen each of these three situations, but rarely with a happy ending:

- the company decides to use a firm to come in and define a new product or service
- the company decides to use a firm to design a new product or service
- the company decides to use a firm to build a new product or service

First I should emphasize that I’m talking here about products or services which are central to your business. There are often some things that are not central. By “central” I mean that if the service were to have a serious outage for some reason, it wouldn’t substantially impact your business. It might inconvenience some people, but things would keep going.

A good example might be your company’s corporate blog. It’s not the end of the world if the blog looks like it comes from another company, or if it doesn’t use the same user authentication system for entering comments versus logging into your customer service help desk, or if you can’t fix bugs in the software because you don’t have access to the source code. In fact, this is often a good example of outsourcing because there are several companies that can create and maintain this blog software better than you can, and this lets you focus on the things that really are central to your business.

I want to talk here about the opposite problem. This is when something is absolutely central to your business, but someone believes it would be better to hire a firm to do this work for you rather than build the capability internally.

I have two big problems with outsourcing core competencies. The first concerns the consequence for the customer experience. The second is the consequence for the long-term viability of the company.

In terms of the customer experience, the main consequence is that it typically ends up ranging from weak to awful. But why is outsourced product software usually so bad?

- it is inconsistent – the site looks like it’s been grafted together from several sources (because it has).

- it is incongruent – because the firms didn’t really understand your customers or users at all (by the time they started to develop a bit of an understanding the contract is typically over).

- it is orphaned - there is no real accountability and ownership – the firm was just doing what someone told them to do in a contract or statement of work.

- it is unreliable - when something goes wrong, there is no single throat to choke; “we just are responsible for this one part and we think the problems are with that project you gave to another firm.”

The recent article “Holistic View of Product” describes how we avoid these issues in general, but this is a much more severe issue when core capabilities are outsourced.

But firms outsource for a reason. I see four common reasons:

1) Because management is not really considering this a core competency and just viewing the web site or mobile device as just another “channel.” The only way I know of to address this is to educate the senior management. It’s really not a hard sell anymore as all you have to do is look across your industry. Unfortunately, sometimes this requires a substantial loss of market share or revenue before they get it and take that hard look.

2) Because someone in management (mistakenly) thinks this will save money or at least they have budget for third-party contracts but not for direct hires. In too many companies, especially large companies, the tail can wag the dog and businesses make poor decisions for the wrong reason. If the company is lucky enough to have an active and enlightened CFO they can often help to correct this, otherwise it’s back to educating management as above.

3) Because the engineering organization is perceived to be so slow and/or the backlog is already so large that management believes they’ll never get this done if they have to wait for their own team to do this. This is more complicated because it might be true that the current organization is moving too slow, but the only real fix is to correct this. But very often the fault of the slow movement lies not inside the engineering organization but in the group that is continuously sending a firehose of features at them, and/or in the proportion of product to engineering staff. Often the architecture is old and dragging the team down as well. In any case, this can and must be fixed.

4) Because management does not believe they have the talent in-house to do the necessary work. This is the hardest of all to correct. Management’s perceptions may in fact be correct. Maybe you don’t have the level of product management, or user experience design, or engineering capability that is required. But of course it’s management top responsibility to develop a strong team, so this is probably more a symptom of weak management. But this is the situation where I am most supportive of using outside resources, but using them to help develop the internal team and capabilities; not to just go create something and throw it over the wall.

Again, you can certainly supplement your team (especially user experience design, engineering and QA) with external resources, but never in the sense that you hand the keys over to other companies and you just play a project coordinator role.

To succeed long-term your company simply must get good at consistently innovating on behalf of your customers, and defining, designing and building products and services that your customers love. It should be obvious, but hopefully everyone can agree that the product organization absolutely must become the expert on your customers, or you’ve got no real chance to do either of the first two (defining or designing).

The Product Discovery Plan

Mon, 12 Oct 2009 09:33:00 -0400

In my last article, I discussed the situation where Product Discovery is essentially not discovery at all, but rather just a mad dash of just-in-time spec writing so that the engineers can be kept busy. I discussed how important it is that the date not be driving everything at the expense of the value of what will be created.

In this article, I’d like to discuss the opposite problem. There are some companies that believe strongly in Product Discovery, but they waste precious time by not planning their work and ensuring that every day in discovery is getting the most learning possible, and that they are making rapid progress towards identifying the minimum viable product.

The level of precise planning required or desired is very much a function of the culture of the company and the skills of the people involved, but in many company cultures, especially larger companies, I find the team needs to create a “Product Discovery Plan” that spells out what the team believes must be done for this project, what resources are needed, and at least a rough timeframe.

What follows are common components of a product discovery plan. I don’t like for people to consider this a “template” because then teams tend to include things they really don’t need to do just because it’s in the template. Rather, think of this as a list of tools each for a different purpose, and your job is to select the right tools for the job. And your manager’s job is to review the plan and then ensure adequate progress is made.

- Discovery Core Team: At the very minimum, the product discovery plan should identify the product manager, lead designer and lead engineer for this project, and then ensure that these people are available for the product discovery activities.

- Discovery Extended Team: Who will be supporting the core team? Do you expect to need the help of a visual designer? Prototyping assistance? A usability testing resource? A specific developer? Someone from QA? Someone from marketing?

- Key Stakeholders: Who must approve this project (who has “veto power”)? Also this can include a list of just generally smart people that you think you should talk to about this project.

- Customer Development Plan: Will this project utilize a charter customer/user/application program? If so, who will be leading this? If not, who are the customers or users that you intend to validate your product ideas with?

- Key Risks: What are the key risks for this project and how to you intend to address them?

- User Research Tools: Does the project need to do some persona work? A review of the site and business analytics?

- User Testing Plan: How do you intend to test these product ideas on actual users? What is the preliminary testing schedule?

- Product Strategy/Vision: Does this area need a longer-term vision before the specific project can be defined?

- Product Principles: Does this area need its own set of product principles?

- Required Level of Supporting Documentation: The core team should agree on what level of additional documentation is required for this particular project – stories, use cases, test plans, etc.

So creating this plan is one step, but the bigger issue is usually ensuring that the product discovery team is actually making real progress towards minimum viable product, and converging on the point where you can begin building this product.

There are two parts to this progress tracking.

First, I argue that it is the job of the leaders of the product organization (head of product management and/or head of user experience) to be providing this level of very active oversight in terms of making real progress on identifying a strong product. To be clear about what I mean by “oversight” here are a set of questions I like to ask the product discovery team at least once a week:

- What customers and users have you actually talked to personally this week?

- What did you learn from these discussions? Were you surprised by anything you learned? What insights did you gain?

- Did you encounter any potential pivots (see http://www.svpg.com/your-business-plan-is-wrong/)?

- Based on what you learned, what are you going to try differently tomorrow?

- When was the last time the engineer on this team reviewed your work and your learnings?

- What feedback did the engineer have in terms of feasibility and also potential solutions?

- Are users responding to the value of this idea? If not, why not?

- What are the main usability issues with the current prototype? What do you intend to do to try to correct these problems?

- What are the areas of the prototype that the engineer is most nervous about in terms of feasibility, and what are your contingency plans on those?

- Overall, do you believe we can get to minimum viable product within two more weeks? If not, should we continue with this effort or move our focus to another opportunity?

The other area of oversight refers to the project management activities of making sure the product discovery plan is executed and that everything is prepared for implementation. This includes making sure that engineering has everything they need to begin work, understanding and managing any timing considerations, making sure there is good communication between engineering, product management and design, and in general moving things through the process and ensuring that time isn’t wasted.

A project manager can be a big help to everyone involved; just make sure that the primary objective remains the goal of coming up with the minimum viable product, and not just document something for engineering.

However you do it, if your organization is enlightened enough to allow you to pursue product discovery rather than simply document requirements, then by all means I hope you don’t waste even one day of this precious time. If you are having a hard time focusing your efforts and converging quickly on a great product, then I hope you’ll try creating a product discovery plan.

Feed The Beast

Mon, 05 Oct 2009 12:18:00 -0400

For those that haven’t heard the term before, “feed the beast” refers to one of the most common problems with product teams, and one of the top reasons for failed projects. It’s very easy to spot. If you find a product manager that is scrambling to finish up his PRD because the developers are freeing up from their current project on Monday and the very thought of the developers not having a fresh spec ready to go sends the product manager (and especially senior management) into a panic, that’s what we call “feed the beast.”

The beast is of course the development organization and the beast does have a voracious appetite. Unfortunately, the beast generally can’t distinguish between something that’s worth eating and something that’s not. Beasts eat PRD’s and we all know what comes out the other end.

This feed-the-beast mentality stems from the observation that the largest cost in a product development organization is the engineers, so it’s important to keep them fully utilized. Ironically, this overly simplistic view results in maximizing utilization (they are busy) but not maximizing results (producing successful products).

Further, this mindset tends to diminish the development organization’s real contribution. They are treated as a software factory optimized for coding rather than a collaborative partner for discovering and delivering successful products. I like to say that if you’re using your developers for only coding, you’re only getting about half their value.

Good product organizations understand that their responsibility is to provide the development organization with something worth building; something where they have evidence that the products that are created will be successful.

Part of this is simply management not understanding the difference between building the right product, and building the product right. But often the company’s culture plays a role in creating this problem.

I love what a great project manager can do to help you deliver quickly (see www.svpg.com/ebays-secret-weapon/), but it’s also true that in some companies project management plays too central of a role, and the entire focus becomes about schedule and resource utilization. This is why normally I encourage project managers to take a back seat during product discovery, and then move to the drivers seat only once you’re sure you want to actually build the product. I find this works well, except in situations where there’s nobody that knows how to drive in the drivers seat during discovery, and I’m going to discuss this situation in the next article.

So what do you do if you are stuck in this “just in time” situation? There are several options:

1. the developers can work on critical infrastructure/headroom activities (see www.svpg.com/engineering-wants-to-rewrite/)

2. the developers can work on fixing defects and improving performance

3. the developers can participate in product discovery activities

In general, we try to build a backlog of useful product specs of about a month or so. This way, if you run into trouble on a project (for example, you test your idea on users and they think what you’re proposing is a big waste of time and they’d never use it), then you have work that is ready to go while you move on to pursue other ideas.

It is also possible that your project team is out of balance. If there are too many developers relative to the number of product managers and designers, then you will perpetually be behind and your organization is not able to properly utilize the developers you have. I have seen some teams where one product manager is trying to define products for 20 or more developers and this is just a clear recipe for poor products. If you’re not sure about the proper ratios, see www.svpg.com/roles-and-ratios/.

Just please remember that no matter what you do, your top priority is to ensure that the team is building something worth building, and that the development team is a very big investment for the company and should not be wasted, either by having people waiting around or by rushing to build something that will just have to be done over again later.

Holistic View of Product

Sun, 27 Sep 2009 06:27:00 -0400

For a startup, where there’s typically just one product team, it’s not too hard for the leaders to keep in their heads a holistic view of the product. However, this quickly becomes much tougher as the company grows first to a larger product and soon to multiple product teams. One of the challenges of growth is knowing how the whole product hangs together.

There are actually three distinct but critical elements to the holistic view:

- Principal Designer (or Leader of User Experience)

To me one of the most important roles in a company is the person responsible for the holistic user experience. This person must ensure a consistent and effective user experience system-wide. This person is sometimes the leader of the user experience team, and sometimes a principle designer reporting to this leader. It is usually an interaction designer or information architect by training. Ensuring a consistent visual design is also important but there are mechanisms to do that, such as style guides which we encode in style sheets and templates. The real difficulty is in ensuring a consistent and effective interaction model across the breadth and depth of the user experience.

There are so many interactions and inter-dependencies, and so much necessary institutional knowledge of the business and the users, that you need to have at least one person that is reviewing everything being proposed for the site that is going to be visible to the user. You can’t expect any individual product manager or designer to be able to have this all in their heads.

- Principal Product Manager (or Leader of Product Management)

In order to ensure a holistic view of how the entire system fits together from a business point of view (product strategy, functionality, business rules and business logic) we similarly need either the leader of the product management organization, or a principal product manager. For large organizations I prefer this to be an individual contributor role (principal product manager) but let me be clear that this is a very senior role (usually equivalent to a director level manager). The problem with also being a manager is that this person needs to be focused on the product itself and readily accessible as a critical resource to all the product managers, user experience designers, developers and QA. This person should be reviewing the ideas and plans of the various product managers.

This is a critically essential role for companies with large and complex business systems, especially with many legacy systems. If this is an individual contributor, he or she should be a direct report to the head of product so that everyone understands the importance of the role and the responsibilities of that person.

- Software Architect (or Leader of Technology Organization)

Finally, in order to ensure a holistic view of how the entire system fits together from a technology point of view, we have the role of software architect. This person is responsible for the holistic view of the system implementation. This person should be reviewing the architecture and systems design of all the software, both systems developed by your own staff as well as any systems designed by vendors. Again, this is a critically essential role for companies with large and complex business systems, especially with many legacy systems, and should be placed in the organization somewhere that makes this person visible and available to the entire technology organization (this is usually a direct report to the head of technology).

I describe this architect role in more detail in this earlier article: http://www.svpg.com/the-architect-role/.

The larger the company gets the more critical these three roles are, and the absence of these roles is usually all too obvious. If the site looks like it was created by half a dozen different outside design agencies, with conflicting user models and poor usability, you’re probably missing a principle designer.

If projects are constantly getting stuck because product managers don’t understand the implications of their decisions or product managers are constantly asking developers to look at the code to tell them how the system really works, then you’re probably missing a principle product manager.

And if your software is a big mess of spaghetti and it takes forever to make even simple changes, you’re probably missing a software architect.

You might ask what happens if one of these people gets hit by a bus or leaves the company? First and foremost, don’t lose these people! Take care of them and by all means don’t give them any reason to want to leave or feel like they need to become a manager to make more money.

Second, you should always be trying to breed more of these people, and each of them should have at least one person they’re working to develop into a strong second. But they are always rare as this learning does not happen overnight and these people are incredibly valuable.

Some companies think the answer to this is to try to document the system to the degree that this is all captured somehow in a way that members of the organization can all go to for the same sorts of answers they use the principle designer, principle product manager and software architect. This is actually the subject of a future article but I will say here that I know several organizations that have tried hard to achieve this, but I have never actually seen this succeed. The systems always seems to grow in complexity and size much faster than anyone can document, and in truth with software, the definitive answer always lives in the source code itself (at least the current answer – not usually the rationale or the history).

If anyone knows of a situation for a significant sized software system or site that has managed to find a way to truly capture any of these three aspects of the holistic view, I’d love to hear from you.

One final note. These three people – the principal designer, principal product manager, and software architect – are obviously very valuable individually, but in combination you can see their real power. Any head of product with access to these people knows he can do some pretty amazing things.

Product Discovery vs. Product Optimization

Tue, 08 Sep 2009 21:00:00 -0400

As readers of these articles know, I am a big fan of high-fidelity prototyping and user testing on current or prospective customers. These techniques form the basis of Product Discovery; it’s the key to discovering the minimum viable product – a product solution that is valuable, usable and feasible (see www.svpg.com/product-discovery/).

However, often I’m asked if these same techniques should be employed for all product changes? While I love Product Discovery, it’s intended for identifying significant new functionality. This is common both when we’re starting a new product, but also when we’re considering significant changes to an existing product, such as a usability redesign, or enhancing the product to meet the needs of a new class of user.

But often the work we do is not about discovering new products or capabilities, but rather our task is to optimize the user experience and/or business results of an existing product. This Product Optimization uses different tools and techniques than Product Discovery, and the scope is generally narrower, but don’t let that fool you as the results can be impressive.

The basic tools of the trade for Product Optimization are Web analytics, and A/B testing support (also known as split testing or multivariate testing).

Good analytics depends on having your site instrumented so that you can in fact know what your users are doing on every page as they make their way through your product. Good A/B testing support lets you try out different approaches with controlled variations, and then quickly see the results of each.

There are quite a few products to help you with each of these capabilities, but with the free Google Analytics (see www.google.com/analytics) and the recently added Google Optimizer for A/B testing support (see www.google.com/websiteoptimizer), there’s no excuse not to at least use this, if not one of the more advanced solutions out there.

Product Optimization is a continuous cycle of controlled experiments deployed to part or all of your user base, with rapid review of the impact, then selecting the best performing options. We continue this until we’ve either run out of ideas for improvement, or we believe we have reached the point of diminishing returns.

One of the things I absolutely love about Web sites and cloud-based services in general is that the technology for this sort of instrumentation and near real-time reporting is so powerful and easy.

When I first start working with a company, if they don’t yet have their site instrumented in order to enable the analytics or optimizations, it’s really the top priority to correct this. I explain that they are “flying blind” without this data, in that they really don’t know what’s going on in their site, and their various ideas for improving things are just theories without the data to support them.

You can go out and watch users interact with your site, and I always find this incredibly valuable in the insights you can gain, but you generally can’t, for example, see the difference between a 5% conversion rate and a 7% conversion rate with this technique. You need relatively large volumes of actual data to see these differences, so generally we do that with live data and an instrumented site.

Typical examples of Product Optimization include working on the customer acquisition funnel – starting with online marketing programs, then landing pages, then customer registration, activation and action (buying or transacting).

I should also mention that Product Optimization works especially well with Agile development teams, as the rapid iterations and relatively minor changes suit the process well. It’s frustrating when you just have some minor changes to test out but the next release vehicle isn’t coming along for months, and then you have to wait months more to incorporate your learnings.

A well instrumented site, with a dedicated Scrum team, combined with a product owner that understands Product Optimization can take a mediocre (or long neglected) site and make significant improvements to the business results in a matter of weeks or months.

With the tools that are available today, many teams have become quite good at Product Optimization, and it may be tempting to try to use these same techniques for Product Discovery. However, just as Product Discovery techniques are generally not well-suited to Product Optimization, Product Optimization techniques are generally not well-suited to Product Discovery. This is due to several factors:

First, with Product Discovery the iterations are usually daily or every few days, rather than every 2 weeks or monthly. Second, during Discovery you want to try very different approaches and be very open to Pivots (see http://www.svpg.com/your-business-plan-is-wrong/), not the type of relatively minor changes that we do in Optimization. Third, in Discovery you want to be out there watching the eyes of the customers and users, and not so much analyzing the data from wider use. Finally, the full Scrum team is not only overkill for Product Discovery work, but it is actually inefficient use of the team and a prototype is typically a better match for the purpose.

Note that for those working on products that are not Web-based, you can still get this sort of instrumentation and reporting, but you’ll need to do a bit more work and you may have to do the tooling and reporting yourself (not as hard to do as it may sound). It’s not unusual for installed software products today to gather usage data and then periodically “call home” to send the data back (aggregated and without personally identifiable information to prevent privacy concerns).

So if you’re responsible for a product, you want to make sure you have the tools and skills needed for both Product Discovery and Product Optimization. They are very different but complementary techniques and every product leader should be capable in both.

Principles of Product Portfolio Planning

Mon, 31 Aug 2009 17:57:00 -0400

Over the last several months I have been working with some clients to revisit how they do product portfolio planning. Essentially the process they use to determine where to invest and how much. I’ve discussed the purpose and the common frustrations with how product planning is done in most software product companies, as well as explored the root causes of these frustrations. We’ve looked at several specific techniques, and we’ve considered the lessons we can learn from the VC industry, incubators, and some companies that have demonstrated the ability to perform this well.

Many of you have let me know that you are frustrated with how your company handles planning, and are anxious to just hear the case for a recommended process.

But it’s difficult to have definitive recommendations because there are some additional factors, especially the culture of the company and the personality of the leaders, that can significantly impact the product portfolio planning model that is the best fit for a given company. However, I do believe that there are some over-arching principles that can guide you in defining an effective process, and in this article I’d like to share these.

1. Clearly Articulate Business Strategy. In countless organizations, the product organization simply does not have a clear and accurate understanding of the business strategy. First, be clear on the distinction between business strategy and product strategy. Second, ensure there is in fact a business strategy. Third, create product scorecards to ensure that the team understands not only what the business strategy is, but how they can directly help to deliver on that strategy. Note that the product organization might have to “help” the business to articulate the business strategy. Do what you can to make it their idea but in any case be sure that this business strategy is clearly articulated and understood and agreed upon by your executive team.

2. Surround Yourselves with Talent. If you want a strong product strategy, make sure that you are leveraging the resources of your company and, if possible, the industry. Find people that will push you and challenge you. Consider creating a Board of Advisors comprised of industry experts that would be too expensive for you to actually hire but would be willing to meet with you a few times a year.

3. Know What You Can’t Know. One of the most critical points is to understand and accept what you simply can’t know at each stage of the planning process. To be specific, if all you have is an objective and a product idea, then at that stage you can’t possibly know what it will cost to build out that idea, and even more importantly, if customers will actually like your idea as much as you do. Your initial business plan is almost certainly wrong. Recognize this, and manage this risk by recognizing and embracing two investment decision points rather than one. The first is whether the opportunity is promising, and the second is whether the product team has convinced you that they have a solution worth building – in other words, you have both evidence from real customers that they want this solution, and the team has a high-confidence estimate of the cost to build and deliver this solution.

4. Require Executive Sponsors. First, make sure every key investment has an executive sponsor. Second, make sure the executive team has a chance to scrutinize and honestly debate each project. Third, make sure that every member of the executive team embraces whatever decisions the team makes and does everything they can to help out any project.

5. Stay Out of the Weeds. Senior management will be tempted to get in the weeds and worry about details and features. Keep them focused on the big picture and the major investments, and if you don’t have teams that are capable of making the right detail decisions, then find new people rather than try to micro-manage from above. The job of the executive team is to ensure the product strategies are good and that the organization is set up to succeed, not to decide the details of features or design.

6. Groom the Portfolio. For each project, make sure you are constantly evaluating whether it should be an area for active investment, reduced to sustaining mode in order to have more to spend on your active investments, or potentially phased out because it’s no longer contributing to the portfolio.

7. Think Long Term. The reality is that most significant product efforts that can truly impact a business are multi-year strategies. They might start contributing much sooner than that, but to reach their potential they will often take several years. The product portfolio planning process needs to ensure that the company is not just thinking a quarter or two ahead. The executives must insist on multi-year product strategies and thinking, then monitor progress along the way.

8. Make It Personal. Many companies, especially larger companies, tend to view staff as interchangeable. But the determining factor is very often the actual individuals that lead the team. Stop avoiding this and start embracing this as an opportunity to recognize and develop strong leaders. The executives should evaluate the proposed team when they evaluate the project opportunity, and the actual team should present the opportunity. Additionally, the executives should insist that the same group that does product discovery continues on to lead the product implementation.

9. Kill or Be Killed. The purpose of product discovery is to identify a product solution that is valuable, usable and feasible. But if you or the team determines they can’t do this either because the customers don’t consider this valuable, or it’s too complex to be usable, or it will take too long or cost too much to deliver, then you must get good at killing these projects. It is far worse to spend the time and money to build and deploy and then find that the product doesn’t sell or isn’t used.

10. Embrace Pivots. When you actually get your ideas on front of real customers, the bad news is that sometimes you discover that they’re not as excited about your ideas as you are. The good news is that you often discover through this process something that your customers really are excited about. We call this a “pivot” and you can either reject these because they’re not your original idea, or you can embrace these because you’ve actually found something customers do care about. Encourage your team to always be on the lookout for pivots.

11. Use a PMO. The executive team doing portfolio management needs ready access to someone that has direct and ready access to the resources available, the capacity of the organization, the current schedules and commitments, and the critical dependencies between projects. This enables the executives to discuss “what-if” scenarios and make informed decisions.

12. Be Brave. Finally, the secret sauce for many successful product companies is that they demonstrate what I call corporate courage. They’re not afraid to compete, even with themselves. They know that eventually all products run their course, and they’d rather obsolete themselves than have a competitor do so. If they believe that something is the right thing for their users and customers, they are not afraid to endure the press or others that may not agree.

Hopefully with these principles you can envision a product portfolio planning process that is effective without being onerous or bureaucratic.

The Two-Week Rule

Sun, 23 Aug 2009 21:33:00 -0400

I need to interrupt my series of articles on product portfolio planning because over the past week I learned of three completely different companies that all had fairly disastrous product results for the same core reason: they delayed talking to customers until it was too late.

Steve Blank has a great line about this: “In a startup, no facts exist inside the building, only opinions.” And of course anyone that reads this blog knows that I believe strongly that the most important thing that a product leader must do is put his ideas in front of real customers and watch their response.

Yet often I meet people that have read my book or attended a workshop and say they totally and completely agree, yet they still hold off for months before they get any real validation of the ideas with the people that matter – the prospective customers and users. And every day that goes by the product team gets increasingly deeper and more entangled with their original idea to the point that now they’re either too scared to show it to customers for fear of having to start over, or they are so confident that it will be great that they think they can just skip to development, or they’ve got developers screaming at them just to give them something to build.

But one way or the other, eventually customers see it and typically the reality hits hard.

So for those people that believe in principle that they need to validate their product ideas with real customers, but are unsure of how “baked” the idea needs to be, I offer this very specific rule: Never go more than two weeks without putting your product ideas in front of real users and customers.

Does this mean your ideas won’t be fully fleshed out yet? Yes and good. Does this mean that customers might not like your ideas? Yes and good. Remember it’s all about failing fast.

You can and should continue to refine your product ideas – it’s not like you have two weeks to define everything. But please, please get out of the office and put your ideas in front of real users while you still have time to adapt. Just assume that you have some big misses in there and your objective is simply to figure out what they are as quickly as you can.

If you are a manager of product managers, you can help by enforcing this rule and facilitating the customer testing, and pressing the product team for learnings after each session.

Your job as a product leader is to define a successful product, and have evidence that the product will be successful, not just your opinion. You won’t find that evidence inside your building.

Watch Cable TV and Read People Magazine

Sat, 15 Aug 2009 02:39:00 -0400

My husband and I were watching the Daily Show the other night on our DVR, fast forwarding through commercials as we usually do.

Out of the corner of my eye, I noticed the text "Palm Pre" and yelled, "Back up!" to my husband. I hadn’t yet seen the Pre and was interested in Palm’s latest ‘Hail Mary.’

A head-in-the clouds (literally) waif spoke in an ethereal voice about days when all the streetlights turn green. I could kind of see a glimpse of the product behind her well-coiffed head. Finally, she held the phone up so I could see it and zipped through three unintelligible screens. The commercial ended suddenly with the phone’s slick black case closing--hiding the whole interface--and the text 'Palm Pre.' http://www.youtube.com/watch?v=iIknaMyJhvw&feature=related.

I’m a big fan of the song they chose, which is the ONLY reason I enjoyed any of the commercial.

Minutes later, an ad came on for the new iPhone. I could see the phone. I saw the apps in action. It was no mystery why the phone they were showing was impressive. After 30 seconds, I was both more interested and educated.

These ads were sandwiched between others for movies and life-style cars--lots of darkness, big action, and sexy people. Especially in fast forward, one smart phone ad stood out. The other didn’t.

I felt sad...really sad for Palm and all the hard-working people whose interesting product remained utterly mysterious to me, a potential early adopter and evangelist.

Relevance Requires Context.
Products need to be relevant for people to pay attention, and that requires setting the proper context. If you don’t understand your customers' context--how messaging appears relative to everything else around them--your marketing won’t work.

A recent Stanford University study found that our hunger for connections is what creates huge audiences for stories about Jon and Kate’s marital woes or Michael Jackson’s death. It gives us social currency and connects us to a larger national conversation. Even 'experts' on a subject, tend to talk about things everyone knows to establish a connection.

Successful marketing requires knowing what’s in the national conversation, and I don’t mean current events. It’s hard for products to seem relevant if its marketing isn’t. This ranges from understanding cultural context to the visuals and messaging competing for people’s attention. Technology marketers tend to be intellectual snobs about mass media, but at the end of the day, everyone--even your most elite customers--downshift their brains.

Watch Cable TV and Read Pop Culture Magazines.
Choose something targeted, which provides both more to study and usually more relevant competition context for technology marketers. But also read People magazine or look at entertainment headlines because the glitzy stuff is what's getting people’s attention. Think about how and if you can tie your product into what’s culturally relevant.

YouTube is also great to browse through because you can see exactly how much traction and audience something has found. Study what’s working and you’ll start to find common threads.

Create a Hook.
Like good pop songs, good marketing needs a hook "P-p-p-poker face, Mum mum mum mah..." (if you don't know that reference, you need to get out more.) Especially if you’re trying to differentiate in a crowded category, your marketing must quickly communicate why people should pay attention. Hooks can be stories, a cool feature or innovative visuals. Regardless of the hook, be sure to SHOW not TELL your product's 'hook.' Watch this phone do this amazing thing vs. "Look at our amazing phone!"

People believe what they see and can judge for themselves. This is why infomercials and direct marketing never die--seeing is believing.

How to Show Relevance Beyond Pop Culture.
Critical reviews, identifying categories or their attributes, analyst reports, third-party studies, success, blogs, comments or commentary, and stories all set context. Become a student of what grabs your own attention or what seems to be getting others' and apply this knowledge as you create or measure your own marketing.

So yes, cruise Twitter even if you hate it. Spend idle time on Facebook. Get caught reading People magazine. Watch reality TV.

It is not just a guilty pleasure. If you’re in marketing, it’s part of your job.

Lessons from Amazon

Mon, 03 Aug 2009 13:36:00 -0400

Several people pointed me to this great little talk by Jeff Bezos, the founder and CEO of Amazon. If you haven’t watched this yet you should. I thought his talk did a great job highlighting a few key points that pertain to my current theme of product portfolio planning and I wanted to emphasize them here:

First, he talks about how important it is to “obsess over your customers.” That really is the basis for everything and I loved how he pointed out that it’s not about obsessing over competitors or pundits, it’s about providing great solutions for customers.

Second, he had some great comments about “inventing on behalf of your customers” and how it’s “not a customer’s job to invent.” Those of you that have been reading my articles and book know that I consider this to be the core of great product – you must innovate and invent, but a) you won’t get the solutions from just doing what your customers tell you to do, and b) you must innovate for a purpose, which is to provide real value for your customers.

Third, he talks about the importance of “thinking long-term” and he explains that if you really want to focus on customers, and invent on behalf of customers, then you must have the discipline to think long-term, where projects might take 5-7 years before they pay dividends for the company. This ability to think strategically and persist is a tremendous competitive advantage for a product company.

Finally, he emphasizes that “it is always Day 1” in that there will always be more innovation on behalf of customers and that it’s never too late to try to do something great. What a great summary of why I love working on product.

So share this video with the execs in your company, and maybe tomorrow you can start working on something great.

Lessons From Incubators

Mon, 20 Jul 2009 08:23:00 -0400

In the last couple articles I discussed product portfolio planning lessons we can learn from the Venture Capital industry. In this article I wanted to discuss a similar but different type of mechanism for managing product portfolio investments, known as business incubators.

For those that don’t know, the way a business incubator typically works is that in exchange for a percentage of the startup, the incubator will provide facilities and enough money to cover the salaries of a few people for a few months, but more importantly they will provide access to people with relevant experience in product discovery – product, design, marketing, engineering, finance, legal, etc.

If the idea pans out, the incubator can provide valuable access to potential investors, potential customers, and advice on how to set up and grow a company.

Most people think of the big tech business incubators like Idealab, Y Combinator, Reactivity and CMGI, but there’s actually a spectrum of ways to help incubate product ideas, ranging from VC’s that maintain EIR (Entrepreneur In Residence) programs, all the way up to large corporate innovation labs like Yahoo’s Brickhouse.

I spent the first several years of my career as a software engineer at HP Labs, which was set up to incubate new product ideas, and then transfer the best of those ideas to one or more of the company’s product divisions. HP Labs was a form of incubator, and they did some great things there and some of the products we all use every day originated in those labs.

Yahoo’s Brickhouse was set up for a similar purpose and in fact many large product companies have some form of industrial research lab, or innovation center or advanced product development group.

What I’d like to discuss in this article are some of the lessons learned by these various approaches at incubating product and business ideas.

While VC’s typically just manage the portfolio investments, an incubator both decides where to invest (product portfolio planning), and also is designed to support the product discovery process, so there are lessons here that apply to each:

1. Incubators are all about making product discovery as efficient and effective as possible. So small startup teams (generally 1-4 people or so) are provided access to supporting expertise like user experience designers, prototypers, ready access to potential users and customers for prototype testing and potential sales, and smart people around that you can talk to about your learnings.

2. Your initial ideas will almost certainly need to change, so incubators encourage you to try your ideas out quickly, fail fast, and then adjust. “Pivots” are welcome and embraced. As long as your learning takes you in directions that are useful, it is all good. It’s about the search for something that reasonates with customers. At Y Combinator, the people they bring on are given t-shirts that say “Make Something People Want.”

3. The initial core founder team should be small, deeply committed and hungry. Most importantly, if the product discovery goes well, this team needs to form the core of the company going forward. Many corporate incubators made the mistake of thinking that they should have one group for “innovating” and leave “productization” to the business units, but without the continuity of the core team this generally fails.

4. Be careful not to throw too much money at the problem. There are many theories about why having too much money and/or time can hurt rather than help, but in any case most successful incubators want the team to feel a sense of urgency and excitement that comes with being frugal. They also know it’s good for a company to start those habits early.

5. In an earlier article I talked about the value of having a “Board of Advisors”. One of the big benefits of an incubator is that the leaders of the incubator can effectively serve as these advisors, and the people get access to expertise that they likely couldn’t have had otherwise.

Incubators seem to go in and out of fashion every few years, but I personally think they can be terrific. If you have a product idea you want to pursue, and a business incubator is willing to take you on, it’s worth considering seriously.

If you work in a larger company, while I would not recommend setting up a separate business entity (like Yahoo did with Brickhouse, or HP did with HP Labs) I would consider making the incubator’s services available to your teams working on product discovery in the business units. More on how to do that in a future article.

Special thanks to my long-time friend Basil Hashem for his contributions to this article. Basil took his startup through the Reactivity Incubator.

Your Business Plan is Wrong

Mon, 06 Jul 2009 10:38:00 -0400

In my last article on “Lessons From the VC Industry” I included some thoughts suggested by a VC friend of mine, Josh Kopelman of First Round Capital. In his thoughts he shared with me he had another insight that I didn’t include because I thought it was so important and fundamental that I wanted to dedicate an article to this topic.

Here’s Josh in his own words:

“Most venture capitalists see several thousand business plans a year – and the one thing they all have in common is that they all are wrong. The moment an entrepreneur hits save, print or send, the plan is out of date. Competition, Technology, and Market Dynamics all effect the plan. Most successful entrepreneurs understand that they need to “pivot” as they get additional data and learning. Many successful venture-backed businesses are “pivots” – PayPal started as a technology to send money from PDA’s, and YouTube started as a dating site.”

Josh went on to emphasize how VC’s understand this dynamic and encourage it, yet product companies seem to fight or deny this reality.

Consider how much weight a typical product company puts on the business plan for their proposed projects. It’s not unusual for product companies to require detailed projected ROI or ECV analysis, market projections, and/or granular cost estimates. And senior management makes investment decisions based on these plans and estimates.

While good VC’s assume these plans are wrong, product companies not only assume they are reasonably accurate and base decisions on them, but then they make the process of change painful and expensive. A pivot is generally not something that is encouraged or even welcomed.

It’s no surprise to me that so many product companies complain of lack of innovation. In large part, the innovations and big insights result from these pivots.

This is why I focus on the broad concept of “Product Discovery” rather than the very narrow “Requirements Specification” that most people associate with product definition. Discovery by its nature must be open to these pivots and course corrections.

(By the way, have you noticed that with every additional word of specification documentation you put down, you become less open to new ideas and different approaches? This is why it’s so important to hold off on writing anything up until after you’ve discovered something worth describing in a spec.)

I do think there are two important flavors of discovery, and I’ve written earlier about the distinction between market discovery and product discovery.

For many product companies, especially startups, the real objective is just to find some product that resonates with a market. Marc Andressen calls this “product/market fit”. This might mean discovering a new market, but most of the time it means discovering a product solution that does the job better for existing markets.

Once a company is more established, very often the company has a specific need, and the purpose of product discovery is to try to find a product that meets the specific need. For example, maybe your company depends on a mobile payment solution, but you don’t yet know what that mobile payment solution looks like. Product discovery is meant to figure that out by coming up with a solution that is valuable, usable and feasible.

So when Josh says that all business plans are wrong, this has big implications for both product portfolio planning, and for product discovery.

For product portfolio planning, we need to pay much less attention to the specific numbers in the business plan, which are very likely wrong, and more attention to the team, the opportunity and the process of discovery.

Sometimes when I explain this to people they think I just don’t like the models or the spreadsheets. But the models are typically fine; the issue is that at the very early stage that most companies create these models, there’s just no way to know the idea’s potential in terms of real customer demand, whether the team can discover a solution that meets the needs, and the eventual cost to build and deliver this solution. So it’s garbage in, garbage out.

A critical part of good product portfolio planning is acknowledging what you can know, and what you can’t, and managing risk intelligently.

For product discovery, we need to realize that it’s not only okay to seek out these pivots, this is what product discovery is all about.

By the way, you can read more of Josh’s thoughts on his blog at www.redeyevc.com.

Lessons from the VC Industry

Fri, 26 Jun 2009 18:59:00 -0400

In earlier articles we discussed the purpose of product portfolio planning and the frustrations with current product portfolio planning. In this article I’d like to look outside the typical world of product companies to a related industry that is in the actual business of making product investments, and that’s the Venture Capital (VC) industry.

First, just so we’re all on the same page, realize that just as the management of a technology company must decide what projects to fund in order to try to maximize shareholder value, the partners in a VC firm must decide what startups to fund in order to try to maximize the return of their investors. So the purpose is very similar, even if today the methods are very different.

Now just like any other industry, some venture capitalists are much better at picking successful product investments than others. But as an industry there is a reason they’ve made so much money. They are not afraid to take calculated risks, and as a whole over time they’ve proven themselves able to produce some pretty terrific returns.

I work with quite a few different venture capitalists from several different firms, and while the practices do vary across people and firms, there are some best practices that have emerged that I would argue have been critical to their effectiveness as portfolio managers.

What are some of the key lessons from VC’s?

- Seed Funding and Product Discovery

VC’s have a very clear distinction between seed stage funding and later stage funding. They know that just because an idea sounds good, it doesn’t mean that the customers will respond the way they hope, that the team can come up with a good solution, and then execute successfully. Some VC firms (as well as Angel investors) focus on this very early stage funding, and others focus on later stage funding.

Contrast this with the typical corporate product portfolio planning, where the management is forced to make all or nothing investment decisions very early in the process with very little real information.

Essentially the VC’s are evaluating opportunity assessments, and seed funding is there to underwrite product discovery. If the idea pans out, and the team proves capable, later stage funding is intended to execute on the idea, get the product to market, and help the product reach its potential.

- Evaluating Opportunities

While every individual venture capitalist looks at investments through his own lens, as an industry VC firms have learned that there are some dominant factors to predicting future success: the magnitude of the market opportunity, the capability of the team and their ability to execute, the promise of the product concept and the intellectual property behind it, and the ability to acquire customers at a reasonable cost.

Significantly, this view of opportunity evaluation is markedly different than the typical corporate assessment involving financial models with detailed plans, pricing, revenue and cost estimates.

At first blush it may seem that the VC analysis is too subjective, and the corporate view is much more analytical, but I would argue that a) the accuracy of a typical corporate financial model created as part of a product proposal is an illusion, and b) the factors that the VC’s are digging into may be qualitative but they are the true determining factors.

Most importantly, the VC’s know that whatever your plan may be today, it is almost certainly wrong and will need to adjust. As you proceed and learn, you’ll need to course-correct based on changes in the market or the technology. VC’s understand and embrace this dynamic and encourage flexibility.

This is in stark contrast to most product companies. Once most companies put a plan in writing, they feel the need to execute on it as it was written – regardless of the learnings from the market, the team and the technology. The company effectively put blinders on, and either ignores change, or even places obstacles to change.

- Willingness to Accept Failure

VC’s know - and expect - that a meaningful percentage of the opportunities they back will fail, and that a few projects will generate the vast majority of the returns. This is completely at odds with how most companies do planning, and there are a couple important implications of this.

First, the VC’s understand that it’s okay to fail, but it doesn’t make sense to throw good money after bad. What’s not okay is to live in denial and to continue to throw funds against bad ideas at the expense of being able to give the good ideas the investment they need to reach their potential.

Second, knowing that many projects will fail, the VC’s spread the risk across a portfolio of investments. Since a VC firm typically has a portfolio of 30-45 companies, they are able to take a portfolio-adjusted view of risk. This allows them to take some really “big swings” knowing that they are part of a risk-adjusted balanced portfolio. Most companies, on the other hand, don’t apply portfolio theory to product portfolio planning. Companies tend to be defensive trying to protect what they have (downside protection) and think very short-term, rather than taking the offensive and going after the key new opportunities aggressively.

- Investment Time Horizon

While everyone loves an investment that yields a great return in a very short amount of time, there is a dramatic difference in the investment horizon between VC’s and typical corporate product planning. So many in our industry were shocked that Apple had invested more than 3 years to develop the first iPhone model, and I can’t tell you how often I heard “our company would never fund something that wasn’t expected to contribute within a few months.”

Yet in the VC world, the investment is generally expected to take years to develop. Part of this is directly related to risk, but also I think there is a better appreciation in the VC world for the concept that building something worthwhile may take more than a quarter or two.

In fact, the average VC technology investment takes over six years to realize its potential. Creating something great requires persistence and focus, and VC’s strive to have clear milestones and clear inflection points in order to monitor the success of their investments.

- Investment Granularity

In the corporate world we often worry about funding at a relatively small granularity of incremental or ongoing investments to existing products. This effectively moves a level of decision making away from the product team to senior management, and it also tends to disincent longer-term strategic thinking.

In the VC world, the decision is whether to invest a given amount (typically a relatively large amount) in a team to chase an opportunity. The VC’s know that the team will have to make course corrections as they go, and they in general try hard not to micro-manage.

- Partner Sponsorship

Another interesting lesson from VC’s is the way they handle the due diligence process and then the decision process. First, if you can’t convince a partner that your idea is good, you go nowhere. But even if you do convince a partner, you’ve still got more to do. That partner becomes your sponsor or champion at the VC firm. That partner will often eventually serve on your board if they do invest, but most importantly, this person is responsible for deeply understanding your project and defending it to the rest of the partners.

This notion of executive sponsorship is missing at many companies. In larger companies, this is often the kiss of death because without a strong sponsor in the executive ranks, you are subject to the political winds, and are almost certain to lose in the next squeeze for resources.

- Partner Dynamics

Just because you have a sponsoring partner doesn’t mean the VC firm will fund you. They will have extensive debate, with you and also behind closed doors. This is where the typical corporate hierarchy can hurt because it tends to significantly reduce the type of open, honest, constructive debate needed to make smart investment decisions.

In a typical VC firm, the partners will vote on your project. Some require unanimous decisions and others don’t, but in either case they make a decision as a team and while you’ll continue to have your partner as a key contact and board member, you find that all of the firm’s partners are there and available to help. They genuinely want you to succeed. They have skin in the game, and there is much less room for politics.

Some of these differences of course stem from the nature of private investment firms versus product companies, but I have found great value in identifying and leveraging best practices in software wherever they might be found, and when it comes to product portfolio management, the track record for most product companies is poor and painful, yet VC’s have built an entire industry around this critical skill.

In the coming articles we’ll discuss how to apply these practice in a corporate environment.

Special thanks to a couple of my favorite VC’s (and former leaders of some great product companies) for their contributions to this article: Josh Kopelman of First Round Capital, and David Orfao of General Catalyst Partners.

Frustrations of Product Portfolio Planning

Sat, 13 Jun 2009 21:07:00 -0400

Continuing with the series on product portfolio planning, earlier I enumerated the purpose and objectives of the product portfolio planning process, but in this article I wanted to discuss the common complaints from executives and product leadership alike about the typical product portfolio planning process used at most companies beyond the startup stage.

I should start by saying that I know of very few companies that are actually happy with how they decide which projects to pursue, and how they should allocate their organization’s resources. But they plow along with largely the same techniques they’ve used for years because there haven’t been many realistic alternatives.

My intention is to change that, and in the coming weeks I’ll share what I argue are some new best practices around product portfolio planning, but first I need to get out on the table the specific problems with the current approaches:

- Probably the most serious fundamental issue is that the senior management is forced to make critical decisions with very little information, and the information they do have often ranges from hopelessly inaccurate to intentionally misleading. The typical approach is to try to quantify the benefits and the costs, either quantitatively with ROI/ECV/NPV type analysis, or a little more qualitatively with a matrix of factors such as strategic fit, complexity, risk, costs, etc. Unfortunately, we all know the output of these models is only as good as the inputs (i.e. garbage in, garbage out). And realistically this decision comes too early in the process to have any sort of accurate estimate of either costs or benefits. I would like to think that most leaders today understand this, but I know that many do not, and I’ve got an article coming soon that speaks to this point specifically.

- The second fundamental issue is that these are usually all or nothing decisions. If you decide to fund a project, you are committing generally to define, design, build, test, launch, market and support. This of course is a very expensive decision, especially when you factor in the opportunity costs.

- The portfolio planning process itself is typically a big time-consuming fire drill for much of the product leadership and general management of the company, usually either quarterly or annually. Because management is forced to make these big decisions, and because so much rides on these decisions, it generates a great deal of angst and work, creating PowerPoint presentations, working with finance to try to craft a business case, and lobbying various stakeholders throughout the company to try to shore up support.

- Partly as a result of the limited real information, there is typically not enough executive discussion and debate of the various investment options. But also we should admit that corporate politics usually plays a big role here.

- Finally, given the realities of corporate life, we know that especially in large companies, a project without a strong executive sponsor has very little chance of weathering the inevitable storms. But this process and the typical organizational structure doesn’t generally force a sponsor.

But nevertheless most companies have some form of quarterly or annual session where the various projects are considered and management must decide which to fund and to what degree. And the rest of the organization – product, design, engineering, QA, marketing and sales – all are dependent on and directly impacted by these decisions.

If, like me, you believe that this is no way to run a railroad, then stay tuned for some very different approaches to this very real problem in our industry.