svpg blog

Top 10 Reasons for Slow Velocity

Mon, 26 Jul 2010 14:45:00 -0400

I work with quite a few product teams, and after a while you start to see patterns. Many organizations are frustrated because they believe that it takes far too long to move from concept to delivery. They often just blame the skills of their developers, which is rarely the root cause in my experience.

In this note I wanted to highlight what I consider the most frequent reasons for slow velocity:

1. Lack of strong product owners. The lack of a strong and capable product owner is typically the largest single reason for slow product. Without such a leader, the team is almost certainly destined to churn. And churn slows everything down, plus it takes a serious toll on team morale.

2. Lack of strong project management. The lack of strong project management is typically the second biggest reason for slow product. Each team needs a true project manager (ScrumMaster for Scrum teams). This should not be the product owner, and it should not be someone with another job. The most important function of the project manager is to remove impediments, and most impediments won’t go away quickly without someone actively chasing them down. We say “pushy but not bossy.” See http://www.svpg.com/product-management-vs-project-management/

3. Infrequent release cycles. Most teams with slow velocity have release vehicles that are too infrequent. On the order of a release vehicle no less frequently than every two weeks. Correcting this typically means getting serious about regression test automation and release automation so that a release candidate can be tested in hours and not weeks or months, and the team can release with confidence.

4. Not including lead engineers during product discovery. The lead engineers need to be key participants in product discovery from day 1. They can often contribute alternative approaches that will be significantly faster to implement, if you include them early enough in the process for the product manager and designer to adjust. If not, their critical input will come too late in the process and the result is, more churn. See http://www.svpg.com/knocking-down-walls/

5. Not utilizing user experience design in discovery and instead having them try to do their work during the sprints. User experience design should be completed before an item gets on the product backlog, and it should be defined “pixel perfect.” If not, the team will be waiting for designs and visual assets (not to mention the very real danger of “feed the beast”). See http://www.svpg.com/design-vs-implementation/ and http://www.svpg.com/feed-the-beast/

6. Lack of product vision and focus. Realize that rapidly shifting roadmap and priorities cause significant churn and substantially reduces the total throughput. This relates to having a strong product owner, but it’s essential that the team have a clear vision of the big picture and how their immediate work contributes to that. See http://www.svpg.com/product-strategy-in-an-agile-world/

7. Lack of dedicated teams. If engineers are treated like chess pieces and reassigned to different areas every project, they won’t gain the expertise, or build the team relationships, necessary for high velocity. See http://www.svpg.com/dedicated-product-teams/

8. Lack of dedicated rapid response team. If the same teams are doing sustaining and escalations work as well as the forward progress work, the interruptions can dramatically slow down the throughput of the team. The critical problems must be fixed, but they don’t necessarily have to be fixed by the same team doing the new development. See http://www.svpg.com/the-rapid-response-team/

9. Inflexible product architecture / technical debt. Often the architecture does not facilitate or enable the rapid evolution of the product. This is not something that can be fixed overnight, but it should be attacked ongoing. See http://www.svpg.com/engineering-wants-to-rewrite/

10. Missing holistic view. It can be difficult for each team to know what the other is up to and how the different parts fit together into a cohesive whole. Teams often thrash and churn because they don’t understand the holistic view and the dependencies and inter-relationships. See http://www.svpg.com/holistic-view-of-product/

There are of course several other root causes of slow product, but these are among the most common culprits. The good news is that each of these can and should be addressed.

However, as important as velocity is, even more important is making sure that the software you do release is actually good software that will make a difference for the business. In my next article I’ll summarize the top reasons for poor product.

A Trend of Global Proportions

Sun, 11 Jul 2010 16:05:00 -0400

I am writing this article sitting on yet another international flight, and I wanted to discuss what I believe to be the start of a truly transformational trend.

I have always enjoyed working with teams internationally and especially in developing markets. There is a newness and enthusiasm about products and technology that is contagious, and I have long believed that if you can assemble a team of smart, talented and passionate people, you can show them the techniques and methods for creating great products.

However, for many years I believed that while you could supplement your workforce by outsourcing talent from other parts of the world, if you were serious about product you really needed to be in Silicon Valley. So much of the ecosystem that we depended on was only here in Silicon Valley.

Today I no longer believe you need to be in Silicon Valley in order to create something amazing.

I would argue that Silicon Valley is still Mecca for technology innovation, however, the differences are much less than they used to be, and the access to local talent can even the playing field.

From my vantage point, our industry has evolved over the past several years, and today we’re on the cusp of another major step.

Initially in developing markets we would find mainly outsourcing. Teams of developers and QA would be hired by mainly US firms to supplement their workforce. Silicon Valley’s thirst for talent combined with our constrained geography (and hence cost of living) demanded this.

Next, as the developing markets gained steam and moved online, and the population itself represented an interesting target market, you’d find mainly US companies going after those local markets. They had needs and we had products. Nothing wrong with that.

But it didn’t take too longer before the talent in these markets start creating their own products for their own markets.

You might be thinking that mostly these are just copycats of mainly US products. Initially this was true. Even though I’m not a fan of copycat products, it was understandable to me. US companies often weren’t taking local needs seriously, which created the need. Also, local teams often lacked the confidence and skills to pursue their own ideas. It’s also true that many VC’s preferred to fund teams to do copycat products. In any case, this was how many entrepreneurs got started.

By the way, copycats happen in the US at least as much as in the rest of the world, and the VC’s play a role in that here too.

This has all been happening for a while now, and increasingly I am seeing startups pursuing truly innovative products for their local markets. But now I think we’re starting to see signs of the final step in this progression: startups creating innovative new products that are intended not just for their local markets, but for the world.

When I meet a startup in a developing market that has done something truly innovative and valuable, which happens increasingly often on my travels, I always encourage them to think about the broader world market. They’re often nervous and even a little intimidated, but it doesn’t take much to help them realize that their contribution is just as needed in the US and across Europe as it is in India, Brazil or China.

One advantage that US companies have is that since their default (and often only) language is English, and since English is an acceptable (although not usually preferred) language in a large percentage of the developed world, US companies are able to get their ideas into a broad set of markets much more easily. And since so many sites have user generated content, that content is also then in a language that others can benefit from.

This is why I push on companies to make sure that they support at least English out of the gate (in addition to their native language). It may not be fair, but it’s in their best interest.

There are still some obstacles to this progression reaching its potential. Some governments make it nearly impossible for startups. Some cultures are very risk averse. Some investors have old biases. But in many parts of the world, the stars have aligned and great product work and innovative startups are emerging.

Some of my favorite product innovation hubs outside of Silicon Valley: New York, Boston, Berlin, Sao Paulo, Bangalore, and Beijing, with scattered teams almost everywhere.

The Rapid Response Team

Thu, 17 Jun 2010 07:29:00 -0400

Have you noticed how fast a team goes when they’re just getting started, but that once the product is live and there are customers and users, that the velocity of the team can slow down to a crawl? It’s an all too common problem, and it causes frustration all the way around. Once you have real customers and/or an active sales team, there are always bugs to be fixed and changes urgently needed. So the development team no longer has a clear focus because they’re now being pressured to fix and change the prior versions at the same time they’re being pushed to create significant new things.

Generally in this situation, nobody is happy - customers feel like it takes way too long to get problems fixed, management feels like the team is working in slow motion, developers feel like they’re pulled in ten different directions and can’t focus on anything, product managers feel like they can’t move the product forward.

Moving to dedicated teams addresses a part of this problem. Portfolio Grooming addresses another part of this problem.

However, fundamentally when the same team of developers is trying to both move the product forward, yet also respond to urgent fixes and special requests, the result is that both the new product work, and the maintenance work, often slow way down.

If velocity and customer responsiveness were not an issue, then having developers support their own code makes total sense, and it’s a principle that I advocate. However, for many teams, the cost of following this principle is simply too much for the business to bear.

In these cases, a practice that I have seen make dramatic improvements along both dimensions is to create at least one special dedicated team that we often call the “Rapid Response Team.” This is a dedicated team comprised of a product manager (or at least a part of a product manager), and mainly developers and QA. Usually these teams are not large (2-4 developers is common). This team has the following responsibilities:

    •    fix any critical issues that arise for products in the sustaining mode (i.e. products that don’t have their own dedicated team because you’re not investing in them other than to keep it running).
    •    implement minor enhancements and special requests that are high-value yet would significantly disrupt the dedicated team that would normally cover these items.
    •    fix any critical, time-sensitive issues that would normally be covered by the dedicated team, but again would cause a major disruption.

This last two cases are a bit tricky to explain. Normally if there is a dedicated team, they would fix their own problems and do their own enhancements, and most of the time they still will. But sometimes they will be in the midst of some major work, and for them to stop and make some fixes and test them and get them out can cost much more in terms of time and momentum than just the time to fix the bug. In this case, the Rapid Response Team might cover it. However, when they do, they still need to discuss and review the change with the developers on the dedicated team.

In large part, this type of rapid response team provides a form of relief valve for the organization. Rather than be put in the position of either always saying “no” and being perceived as unresponsive, or else always saying “yes” and then dramatically slowing down the velocity of the new product work, the organization can now respond to customer issues and minor items in a timely fashion, yet still get fast progress on new product work. I promise you that your executives and critical customers will be so happy to be able to get at least many of their hot button issues addressed quickly, and this relieves a good deal of pressure on the organization.

The main objection to creating a rapid response team is that it can be hard to convince developers to work on this team, because it’s perceived as a bug fix team. That’s fair, but I find that there are some techniques to mitigate this. First, when a new developer (especially a college hire) is hired into a team, this is a perfect place to start as he or she can get the chance to learn the code base and get the holistic view. Second, one of the responsibilities of your senior developers is to teach the new developers, and if a senior developer is paired with one or more new developers, he can review and mentor the new developers. Third, being on this team is not a life sentence. After 6 months or so it’s typical that the developers will rotate out and onto a different team.

The velocity of software teams is a funny thing. The math doesn’t really add up the way you’d think it would. A small team that can focus on something can make amazing progress. Interrupt them frequently and things slow to a crawl. What I have consistently found is that if the development organization pulls out 2-4 developers from other teams, and has them focus on Rapid Response, then the original (but now somewhat smaller) teams makes faster progress, and the customer responsiveness to critical issues gets dramatically better.

If you think this might work for you but you’re not completely convinced, you can try it on just a subset of your development organization and compare the results.

New Voices in Product

Tue, 01 Jun 2010 12:34:00 -0400

I’m often asked about the blogs I read and the people I look to for inspiration as to thought leadership when it comes to product. Sadly, for several years I couldn’t give a very good answer to that, however, today there are some exceptional people that have published their experiences, and I thought I would highlight my favorites here. If you like the topics that I write about, I’m confident you’ll also like what these people have to say.

Ben Horowitz - http://bhorowitz.com/

Ben is the newest voice in the product community, and ironically, he started writing when he left the product community to become a VC. I first met Ben at Netscape, and I was at least smart enough to realize that Ben was a whole lot smarter than I was, and I was one of many people there that benefited greatly from knowing and learning from him. His career went from product management, to the CEO of a rapidly growing startup, to a general management role running a very large part of HP. But now he invests full-time, and he’s giving back by sharing some of the many lessons he’s learned on his new blog. Ben likes to be provocative, but he is very thoughtful and not afraid to call it like he sees it. Here’s a great example.

Eric Ries - http://www.startuplessonslearned.com/

Eric is probably the key figure behind the Lean Startup movement, and he is an exceptionally gifted thinker and writer. He has the ability to take complex points and distill them down to a few key paragraphs that nail it. I honestly love reading his articles. He comes at product from an engineering perspective, with an emphasis on startups, but in my view, if you are in any way working on technology products – product, engineering, design or marketing – at small or large companies, you should be reading Eric’s thoughts. Some of the terms he uses are different, but I consider his views as close to mine philosophically as anyone I’ve come across to date. I’m working on an article that maps the Lean Startup concepts to the terms that I have used in my writing. Here’s a good example of Eric’s writing.

Steve Blank - http://steveblank.com/

Steve is not really a new voice in product, as he is an industry veteran and has been writing for a while. He authored the book “The Four Steps To The Epiphany” that I have long recommended. He comes more from the marketing perspective, and also from the Enterprise software world, but the principles he advocates are relevant across virtually all technology companies, especially startups. He’s closely associated with the Lean Startup work, but I find his perspective unique enough that I like to read both his and Eric’s views. Here’s a good example of Steve’s writing.

Fred Wilson - http://www.avc.com/

Fred is actually not a product guy, he’s a long-time VC, however, I mention him here for two reasons. First, he really loves product, and he truly immerses himself in the technologies of the internet. This makes him an extremely insightful investor (just take a look at his track record), and especially for those of you considering doing a startup, his views are very relevant and timely (and any of you would be extremely lucky to get him on your board). But the main reason I mention him here is because Fred has been writing a series of posts called “MBA Mondays” that strives to educate aspiring entrepreneurs and product people on the financial aspects of building and running a company. A while ago I wrote an article “Make A Friend In Finance” that makes the case for why product people must understand the financial dynamics just as they need to understand the technology. Well, for many of you, through his writing and sharing, Fred can be that friend.

There are several other voices that I read regularly and have a great deal of respect for, but these four thought leaders you may not have heard of before, and I think you’ll benefit from their experiences.

An Open Letter To The Design Community

Tue, 11 May 2010 22:38:00 -0400

I hope that everyone that reads this knows that I am one of the biggest advocates in our industry for user experience. Because I generally work with the CEO’s, VP Product, and product managers of technology companies, I am probably in the best position to explain to them the importance of user experience design in coming up with great products. I am not a designer, and I don’t have a design agency I’m trying to sell, so they know I have no personal interest other than I just want them to create better products.

Over the past several years I’ve put together a pretty strong business case for user experience (UX), and one consequence of working with me is that most of the time the companies immediately try to embrace the role of UX. The companies I’ve worked with have opened hundreds of jobs, I’ve personally helped place dozens of designers, and I constantly advocate for the inclusion of design in the process of product creation.

That said, I could use a little help.

When these companies hire designers, most of the time the results are immediate and unmistakable. But sometimes there are bumps in the road to better products, and often these bumps are caused by designers either inadvertently or mistakenly falling into some common traps.

Here are the major areas where I often see problems:

Know Your Audience(s) – As designers, you basically have three key audiences. Your colleagues in design and product management; the users you’re designing for; and the execs and other key stakeholders. Please understand that these are three very different audiences, especially your execs. To be specific, don’t try to show taxonomies, concept maps, site maps, task analysis grids, design process maps and even wireframes to execs. These tools are all useful for designers, but not for execs. Please trust me when I say they will only serve to freak out the execs. They might humor you and try to look impressed, but then they call me and complain that they have no idea what you said, what the heck you are doing, and now they’re really nervous, and I have to talk them off the cliff. Please people, if you want to succeed at your company, just remember this rule: the only thing that works to explain your design to execs and stakeholders are prototypes, the higher the fidelity the better. Do yourself a favor and keep the sausage making within the design team. Some execs will want to know how you got from here to there, and that’s okay, so long as you start with them understanding where “there” is. Note that this doesn’t mean that you can go dark on your execs for extended periods of time.

Be Sensitive To Change - when your company does finally decide that user experience is important, please don’t come back and propose to your management a three to six month design phase of contextual inquiries/ethnographic research, persona development, concept mapping, undirected user testing, heuristic reviews, and competitive analysis, etc, all before you can get to something they can understand. Now, I happen to be fans of each of these techniques, but you need to be smart about how you introduce these techniques to the process and the organization. The key is to separate out the baseline customer learning activities (which should be ongoing and in the background), from the project specific work. And with customer learning, when introducing this into the organization, look for some quick wins, and always share generously what you’re learning about your customers.

It’s About Customer Learning – people tend to think of UX as usability, but usability is typically the easy part, and, for example, calling it “usability testing” understates the importance and role. You’re responsible for much more. In general, you want to position “User Research” and the UX team in general as the resources that enable rapid and continuous customer learning. You’ve got several tools to learn about customers, some qualitative, some quantitative, some based on prototypes and user testing, some based on split testing and analytics. But it’s all about facilitating rapid and continuous customer learning.

Time To Step Up - the design community has long argued (rightfully) that you need to be included from day 1, but this means that your job is not simply to design pages based on what comes down from the Product Manager in the form of “the requirements.” It’s your responsibility to help figure out what the product needs to be, and this means the requirements. If you tell the product manager to come back once he makes up his mind, you are severely limiting your ability to contribute, and very likely condemning the product to mediocrity from the start. The product manager is ultimately responsible for the decisions as to functionality, but you need to help the product manager identify what’s really required and what’s not. This problem is especially common when the designer comes from either a very waterfall process background, or an agency that is used to doing work based on contracts and not starting anything until the requirements or at least a creative brief is defined.

Role Confusion – at many companies, when I first start working with the execs, they don’t understand the difference between the types of designers. Often, they just have one person (usually a visual designer) in the role and they complain to me about the effectiveness of the design. I find it important to explain to the execs the difference between interaction design, visual design, and user research. Mostly the designers at the company are grateful as they have often been arguing that the company needs to hire either an interaction designer or a visual designer, but it was falling on deaf ears. Sometimes we need to be creative to come up with an effective mix of skill sets. I recently visited with an interaction designer friend of mine at his startup, and he was showing me some of his work and while I knew him to be a very strong interaction designer, his visual designs were always pretty weak. But this stuff was great work. I asked him how that happened, and he confessed to me something interesting. He said that he had a visual designer friend that was at another startup, and that she was in the opposite boat; she had strong visual design skills but never had any training in interaction design. So they worked out a nice little arrangement. He helps her with the interaction design of her projects, and she helps him with the visual design of his projects. The result is that they are both producing much better designs for their startups. This was possible because both of these people were honest with themselves on their skill sets, and they both appreciated what the other could contribute. There are of course some designers that are very strong at both interaction design and visual design, and while I think this is worth striving for especially in senior designers, in my experience this is pretty rare.

Titles – usually one of the first actions a company takes after I engage with them is to start to staff a UX capability. So the execs start searching but they quickly get confused with the potpourri of titles. Honestly it just makes the UX community look like it doesn’t have its act together. From my perspective, we need to pick our battles, and this isn’t one of them. I’ve long ago adopted Alan Cooper’s titles of “Interaction Designer,” “Visual Designer,” and “User Researcher.” I occasionally use the title “Product Designer” for those few that really can represent the holistic design of the product – including interaction design, visual design and sometimes product management as well. Most of the confusion is with the various predecessors and derivations of interaction designer, including old titles like “information architect,” “human factors engineer,” “UX designer,” “interface designer,” “UI designer,” “user interface architect,” and “user interface analyst.” Same problem with "usability engineer," "usability researcher," or "usability designer" when talking about user researchers. I am glad to see our industry finally standardizing on “User Experience” for the design organization as a whole. If you’ve got one of these old titles and you want me to help you get a job, you’ll want to use switch to the standard title. Again, I didn’t pick any of these names, and you could split hairs on any of them, but let’s please not waste our energies there.

On the subject of prototype testing:

- always make sure the product manager and interaction designer is present, even if you have to drag their ass to the test. If you’re one of the few people left that still think these people should be sheltered from the actual user you need to either get with the program, or get out of the way because you are hurting your company. Sorry to be so harsh but this is too important. I have seen too many product managers that read your report, and discount your findings because they assume either you are an idiot, or the people you brought in for testing are idiots (or both). Make them watch.

- realize that the moment of greatest learning happens after the usability testing portion of a prototype test. At this point, the user actually understands what you’re trying to discuss with them, and you can have great dialogs. So don’t over script this. Allow the product manager to interact with this user and see where the conversation goes. You just might discover a pivot that changes the course of your company.

- an informal e-mail with key learnings and results sent the same day, is much more valuable to the team than a formal report sent a week later. Don’t bother with formal reports – your time is too valuable for this and they’re hardly read anyway.

- except in very rare cases, don’t propose a round of usability testing just before launch. It’s a no-win situation as it’s too late to do anything about the problems you find. Do your testing in the first weeks of the project, using prototypes, when the results can actually be used. It’s okay to test again after the launch using the live product.

- not everyone will agree with me on this, and it’s the subject of a future article, but I no longer waste time testing paper prototypes or wireframes on users. Just as they don’t work with execs, they just aren’t very useful with users. Push the team to get a high-fidelity prototype as fast as possible. The tools have never been better so it’s not hard, and most importantly, that’s when the real learning begins.

I know that for many of you I am preaching to the choir. But if not, I hope you take these pleas to heart, as they are all meant to help you succeed at your company and enable user experience to be viewed as absolutely central to continuous customer learning and product innovation.

A special thanks to designers Jeff Herman, Kyrie Robinson and Audrey Crane for their feedback on early versions of this article.

The Office Of Silicon Valley

Thu, 06 May 2010 13:47:00 -0400

Regular readers of this blog know that I’m all about true collaboration, where product leaders, designers and engineers work together to discover products that customers love. Mostly I talk about the process and techniques involved in this, but today I wanted to talk about the physical space and work environment that can be optimized to nurture and support this.

Much has been written already about what Google and Facebook and others have done to create a work environment that’s truly conducive to collaboration and creativity. There’s also been lots written on setting up a good physical environment for Agile teams.

I wanted to reinforce what others have said about what makes a good environment, but I wanted to go further in this article and talk about an effort to create this kind of space precisely for the people that need it the most, yet are least likely to be able to afford it: very early stage startups.

Early stage startups literally live or die by their ability to discover a viable product (what others call “product/market fit”). At the earliest stage, the typical startup is usually run right from the founder’s living room or garage or meeting at Starbucks. However, at a certain point, usually when they get a little seed or angel funding, they decide they’re ready to get their first office space.

But first-time entrepreneurs especially are usually surprised at the cost in terms of time and expense to acquire and provision an office – most want you to negotiate a long-term lease, maybe you even have to pay to build out some walls or cubes. Once you have the space, then you need to buy a bunch of office furniture, set up your IT infrastructure – networks, servers, printers, etc. All this costs money that most startups could be putting to much better use.

And then once you get going, especially as you get further along, you start worrying if you need to hire people to help with naming and branding and marketing, and getting lawyers to help with incorporating and dealing with patents, and accountants to help set up billing and payroll and taxes – you get the idea. Today it’s a big leap of time and money just to get your little 3 person startup off and running. Further, there is so much uncertainty around early stage startups that it’s not even wise to make long-term commitments even if you have the money to do so.

One solution to this is to sign up with an incubator. I am actually a big fan of incubators, if you can get in with a good one and if you’re willing to give up the equity. However, I’ve found there are a great many startups (the vast majority) that either don’t want to give up the equity, or often they are too early to make a compelling pitch to the incubators, so they’re denied or don’t even apply.

So I went to a long-time friend of mine, Bruce Williams, that owns a prime Silicon Valley office building, located right in the heart of Silicon Valley, and persuaded him that there’s a need in the valley to help these early stage startups get going quickly and inexpensively, and together we’ve come up with this idea of “The Office of Silicon Valley.” I should state up front that I have no financial interest in this, and in fact my new office is smack in the middle of this space, and I pay full price. But I am good friends with him and as you’ll see below I am one of the advisors to the startups that sign up.

Bruce and I started off by asking ourselves what the ideal environment would be for very early stage, lean startups. We wanted to create a space where a startup, with anywhere from 1 to 15 people, can be productive immediately – literally in hours – with no expensive long-term commitments, no purchases of furniture or office infrastructure, and the ability to add new employees at any time just as easily, and importantly, access to a set of advisors to help increase your startup’s chances of success.

We just finished building out the space, and you really have to see the environment to get the full experience, but startups get a blend of private offices, project rooms and several thousand feet of open space, designed especially for Agile teams. There are also several conference rooms, a big state-of-the-art board room, all new furniture that is easily movable and flexible with tons of rolling white boards, and great shared facilities including a a modern, fully equipped kitchen, a café with espresso machine, ping pong table, health club access, and monthly beer busts.

It’s all designed to help startups stretch their cash and give them the flexibility they need to add people if and when they need to with no commit and constraints. All of the office infrastructure is already in place, there is no waiting for service, staff, furniture, or equipment installations.

In addition to the physical space, we wanted to take a page from the Incubators and provide access to a range of advisors and support services:

mentoring advice in business, product, sales and marketing strategy
marketing – branding, identity, positioning
technology – scaling, recruiting
design – graphic design, visual design, interactive design
user feedback – user testing, user surveys, site analytics
warehousing – inventory management, shipping and logistics
IT – network set up, teleconferencing
legal – patent, incorporation
financial – raising capital, accounting, payroll

There are advisors for each of these areas (see http://www.theofficeofsiliconvalley.com/web/advisors), and access to discounted pricing when a company has special needs.

If you’re an early startup and you’d like to come visit, check out http://www.theofficeofsiliconvalley.com. The office is in Sunnyvale, right between Yahoo and Palm, and just minutes from Google, Facebook, Microsoft, and PayPal.

Even if you are at a bigger company with your own offices, you may want to come by and see the space just to get some ideas for your own space (or just play some ping-pong).

You're Not Helping

Mon, 26 Apr 2010 17:20:00 -0400

Most of my writing is aimed at the product organization, and in helping that organization evolve to where it needs to be to truly serve the needs of the company. I have also written about how the leaders of the company can help facilitate this. This article, however, is aimed at those leaders that are not actually helping, even though their intentions are typically good.

So here are what I would list as the top 10 behaviors in which leaders aren’t actually helping:

1. Drive-by Management. Also known as “swoop and poop.” This is the typically extremely busy leader that drops in occasionally (every few days or weeks) and does a harried brain-dump of all the ideas or frustrations he’s saved up since the last time he came by. The issue here isn’t so much the frequency of interaction, it’s the nature of the interaction. It’s typically very one-way and demoralizing. Instead, try changing the nature of your interaction to discuss what the team has learned since the last visit, what experiments have you tried and what are you intending to try next.

2. Micro-Managing. This is a tough one for so many product leaders, as they typically really do want their teams to step up and they want to empower them, but the leader may not feel the team is ready or able to step up. Unfortunately, this quickly becomes self-fulfilling, as a micro-managed team quickly becomes disempowered and comes to the conclusion they should just wait for instructions. My view is that you need to make sure you have people in your product organization you can entrust, and then you need to empower them and hold them accountable. The alternative just doesn’t scale and doesn’t yield the type of motivation necessary for sustained product efforts.

3. Customer Control. Some leaders think that they must control all access to the customers and prospects, either because they feel that’s their job, or because they don’t trust the product people not to say something inappropriate, or that the product people should stay with the team working on building the product. However, unless the product team can establish itself as the experts on the customer, the products will never be where they need to be. And if you really can’t trust the product team to know how to behave in front of customers, then you need to get people there that you can trust. Or send your product managers to “Charm School.”

4. Bright Shiny Thing. It is normal for those of us that love this industry and technology to frequently get excited about new opportunities and new technologies, but we’ve all seen the leader that changes his mind every few weeks on what the “next big thing” is going to be. As the leader, you do have some silver bullets to be used when a truly big opportunity does come along, but you only have a few, because once you’ve done that too many times, it’s like the boy that cried wolf. The team learns to not really pay much attention because they know you’ll change your mind again in a few weeks.

5. Last Customer Visited. A problem commonly associated with Drive-by Management and Customer Control, is the leader that completely guard rails after each customer visit. They get called into a customer that is having big issues, and then they come back and want to change everything based on that customer’s issues, which lasts until the next time this happens. In my experience, this is most commonly a problem when the leader only visits customers occasionally rather than frequently, and is a bigger problem at enterprise companies.

6. Confused Business Strategy. Very often the product team is thrashing because they either don’t understand the business strategy because it hasn’t been clearly articulated, or because the business strategy keeps changing on them. A business strategy typically has a profound effect on the product, so clarity around this is one of the key responsibilities of the leadership. The head of product may need to help the leaders to articulate this strategy, but the leaders must own it.

7. Acquisitions without Product Due Diligence. Leaders often get very excited about potential acquisitions, and they know they must do financial due diligence, but often they forget the product due diligence. Everyone in our industry knows how low the success rate is of mergers and acquisitions, yet it’s amazing to me how few are willing to do a post-mortem as to what they could have done differently to have achieved a better outcome. You can go a long ways towards helping by including product (and technology) due diligence.

8. Confusing Risk Aversion with Risk Mitigation. When companies are just starting out this is usually not so much of a problem because you don’t have much to lose, and you’re all just doing everything you can to find that product/market fit. However, once some measure of success has been achieved, it’s normal for the organization to move into the mode of trying to protect what they have rather than continuing to move aggressively forward. Risk aversion is when you’re scared to take the risks you need to in order to move forward. However, it’s the job of the product organization to mitigate those risks so that you can continue to experiment and learn without putting the existing business at risk.

9. Engineers and Sales People. There are a surprising number of leaders out there that still believe deep down that the only people that really matter are engineers (to write the code) and sales people (to sell the product), and the rest of the organization is essentially overhead. Old beliefs die hard. However, even if this is what you believe, by all means don’t ever say so out loud. You will demoralize the team and likely lose the very people that your company depends on for its future.

10. Demonstrating You Care. As my friend Danny Shader says, the organization cares about what the leader cares about. If the leader doesn’t demonstrate every day that he cares about your customers and your product, then the organization won’t either. Do something every day to demonstrate this caring.

I want to thank a product manager that I know for his suggestion of this topic and the title. I’m not naming him here just in case his CEO sees this article ;)

The Domesticated Computer

Sun, 04 Apr 2010 15:16:00 -0400

In the early 1980’s, I was a very young software developer working at HP Labs, and this was when personal computers had been out just a few years. The computers were getting faster and more powerful every few months, yet users really struggled to interact with them. The head of our research lab, Joel Birnbaum, posed the question: “Why do most people not like their computers?”

Sadly, I would argue that the situation hasn’t changed all that much since then.

I was in an airport just a couple days ago watching a couple sales professionals from some tech company cursing out loud at their PC because some software got installed by their IT department, and now they couldn’t run their demo.

Sure, those of us in the industry are usually okay, but how many of you, like me, have to spend time on the phone helping relatives that have messed up their computer, or trying to figure out just what your kid installed that has slowed the computer to a crawl?

As far as I’m concerned, Windows is still stuck in the 1980’s. A Mac is better, but it’s still very obviously a computer.

Joel argued that the answer was to be found in the children’s book The Little Prince by Antoine de Saint-Exupery. In that story, a boy meets a fox, and the fox tells him, “To you, I am nothing more than a fox, like a hundred thousand other foxes. But if you want a friend, tame me. One only understands things that one has tamed.” This inspired his vision of “the domesticated computer,” one that would adapt to people rather than asking people to adapt to it.

I remember that we thought we could do this within 10 years. Well, that turned out to be pretty optimistic, and it wasn’t us that did it.

Yesterday I picked up my iPad, and after having spent the past 24 hours with it, I would argue that the world now has its first domesticated computer.

People are talking about how it’s such a great media device – optimized for things like reading books or magazines, watching videos, and playing games. But I would argue that while this is true, the reason is because it’s the first “computer” where the computer itself didn’t get in the way of the user experience. You can just simply use it.

For the most part, a finger and some normal gestures are all you need to do most typical activities. Certainly the iPhone got us all ready for this model, but the iPad takes the interaction model further in that it’s both immersive and invisible at the same time. Things like keyboards, a mouse, menus and modes all get in the way of the actual experience, and the iPad largely does away with all that, and it’s just you and your content.

One of the things Joel did to communicate his vision of the domesticated computer was to commission an artist to create a poster which he then gave copies out to all of us. I did save the poster for several years because I really liked it, but it’s long gone and I tried to find an image online but unfortunately this was before digital cameras so no luck. But if my memory serves me correctly, it was a peaceful scene of a woman sitting alone at her breakfast table, with a cup of coffee and a view of the Bay out her window, and her computer is this unobtrusive, stress-free companion. The iPad would have been right at home.

Congratulations to everyone at Apple that worked on this device and the ecosystem that supports it.

Technology First vs. Needs First

Tue, 30 Mar 2010 10:24:00 -0400

There’s a debate that’s been going on in the design and user research community because the legendary Don Norman wrote an essay in which he did an about-face and decided that doing user research to start a project was mostly a waste of time.

That’s an oversimplification – he actually was only talking about those seeking the big, society changing innovations like the airplane, the telephone, and indoor plumbing. He argues that in each of these cases, first the underlying technology had to be invented, and then only later did we discover uses for it. So his point (and title of his essay) is – technology first, needs last (see http://www.jnd.org/dn.mss/technology_first_needs_last.html).

In part I think he’s trying to shake up those in the design community that advocate a very dogmatic approach of first doing weeks or even months of research to determine needs (e.g. ethnographic research, market research, user research), and only later come up with the technology to deliver on these needs. I’ve also known many of these people that believe this is how innovation is supposed to happen.

Unfortunately, while I think there is an important truth to Norman’s observations, I think his conclusions have confused a lot of people.

I’d like to use this debate to try to underscore what I think is a fallacy of those that believe needs come first, and those that believe technology comes first.

In fairness, for typical, incremental innovations like improving the effectiveness of a web site, Norman thinks that observing users and determining their issues first and then using those learnings to drive technical solutions is great, and I would argue that covers the majority of what most of us do in product. Not many of us have had the chance to work on something that radically changes society.

However, for most interesting innovations, it’s not that technology comes first and then needs second, and it’s also not that the needs come first and then technology second. Rather, it really is a collaborative and parallel effort between product, design and engineering to come up with solutions that are both possible/feasible and useful/valuable.

When Fred Smith innovated to create what would become FedEx, it was a beautiful blend of combining a long-standing need (getting a parcel from anywhere to anywhere overnight) with a solution that was just now possible – a fleet of jets using a hub and spoke system and some impressive logistics software and hardware.

When the TiVo team innovated with the DVR, it was a beautiful blend of a long-standing need (recording was such a pain with video tapes and we hated being forced to watch commercials) with a solution that was just now possible – a low-cost Linux-based appliance with a very large hard disk and some very impressive video management software.

Apple is full of examples of just such elegant combinations of technology and need, and the iPad is just the latest.

Are FedEx, TiVo and the iPad as fundamental to society as the invention of the airplane or indoor plumbing? Maybe not. But are they non-incremental innovations that have had a profound impact on their respective businesses and their customers? Absolutely. And in every case this wasn’t just pure technology research hoping to one day be useful. Rather, they were all innovations built on the back of hundreds of other innovations, but without question driven by the desire to solve specific hard problems addressing real needs.

Now, I think the value of Norman’s argument is that none of these innovations required months of formal market research or ethnographic research in order to understand the user or market needs. No, the real challenge was in coming up with solutions that were feasible and usable. The need wasn’t the issue.

Norman’s argument is similar to the argument against Waterfall or marketing-driven products. Spending a bunch of time up front defining the problem sounds logical but isn’t the way innovation works. And of course we learned a long time ago that you can’t get the solutions from the customer because they don’t know what’s possible.

So while I agree with Normal that spending a lot of time up front is not time well spent, I do believe there is value in framing the need or problem to be solved, as this often opens your mind up to alternative approaches to solving the problem. But I argue for a very quick problem definition statement (e.g. an opportunity assessment).

But I think the deeper issue here is that this overly simplistic view of “technology first” or “needs first” obscures the real dynamic of what happens during product discovery.

I would argue that it’s not very hard to start with a clear need, but product discovery is really about trying to find a solution that addresses that need (it’s valuable), is usable and feasible. Product discovery can have lots of outcomes:

- Sometimes we validate that this need is real and users are hungry for a solution, but sadly the solution isn’t yet technically feasible – either because of missing or immature core technology, or because of cost (development time or investment required), or because of performance. I never like to give up too quickly on feasibility because so often I’ve been surprised by what the engineers can solve when you include them in the discovery process, and give them a little time to think about it and try out different approaches.

- Sometimes we find that users are not nearly as concerned about the need as we were, and it’s really not such a great product idea after all. Or a variation of this is that we discover that there are reasons behind the current solution and they are motivated to resist changing to a better solution. Happens way more often than we like to admit.

- Sometimes the need is real and the technology is feasible, but the solution is just so complicated or foreign that users can’t figure it out, or are unwilling to invest the time to learn.

- Sometimes the very act of putting your ideas in front of users and letting them play with it (and open their eyes to what’s possible) opens up new possibilities, occasionally even more powerful than your original concept. We call that a “pivot,” and it’s one of my favorite surprise outcomes of product discovery.

- Most of the time, however, once we put our ideas in front of users, and we can see which aspects of their needs are addressed well and which aren’t, it provides us with the insights and understanding we need to refine our solution, sometimes in minor ways and sometimes in significant ways, but we iterate and zero in on a good solution – one that is valuable, usable and feasible.

It’s not always pretty, and it’s not always predictable, but one way or the other, you’re combining a real need with something that’s technically possible.

I think the lessons to be learned from this debate include not only Norman’s point of not going overboard on user or market research before you start considering feasibility, but also on the importance of viewing innovation as a true collaboration between product, design and technology where we strive to discover solutions that are valuable, usable and feasible.

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.