I have already written about all the common roles in a product team, but in some companies, there is another role that exists and it goes by various ntitles including Subject Matter Experts (SME), Domain Experts, and Business Analysts. The defining characteristics of these people is that they are experts in the particulars of what the business does. For example, it’s normal for tax software companies to have tax experts on staff, and for payroll services companies to have a few people that have deep knowledge of
the national, state and local regulations regarding compensation and payroll taxes, and health care software companies to have physicians, nurses or other medical specialists.

In general, knowledge of the application domain is squarely in the responsibilities of the product manager, but for some products, there is so much specialized knowledge that it absolutely makes sense to provide the organization (especially the product managers) with direct access to true domain experts.

The product manager will utilize these subject matter experts in several cases. During product discovery, they will use these people to gain deeper insight into the market, the users, the domain and especially the necessary business logic. Similarly they will be very useful to the QA organization as they work to define test cases and understand expected behavior, and help with acceptance testing.

You will need to use care not to consider these subject matter experts as a substitute for talking directly to customers and users. In general, your subject matter experts will not be representative of your customer base. If your customers actually had direct access to people like your subject matter experts, they probably wouldn’t need your software. Your experts will know much more about the domain than a typical customer, and of course they will care much more about your company than any customer would.

Organizationally, companies often don’t really know where to put the subject matter experts. Sometimes they are part of the QA team, and sometimes part of the product management team, and other times you find them just hanging off to the side of the org chart. I prefer to see them closely associated with the product management team because primarily they are a shared resource to the product managers, and the product managers need to be encouraged to use them early and often in their product discovery work.

This is not a role that most companies need in that it is usually reasonable to expect the product managers to become expert in the domain, and to play this role for the product. But for certain products where the domain expertise required is extensive, this role can be a valuable, highly leveraged resource for the company.

Email to a friend

Sign up for the free newsletter here.

Quite a few companies that exist today began life as something other than a product or Internet software company. Perhaps your company began as a large brick-and-mortar retailer, or an airline, or a financial services company.

While it is true that these companies all create lots of software to run their businesses, typically these companies are not set up to produce the type of software that they depend on for their business today.

For example, the retailer creates (or buys) software to coordinate and manage inventory, distribution, billing, and point of sale systems. And the airlines write software to manage the logistics involved in flights, crews, reservations, payment, and fleet maintenance. And the financial servicescompany writes software to manage their customer’s assets and investments.

But over the past 10 years, virtually all of these companies as well as those from dozens of other industries have realized that they need to use the Internet to engage directly with their customers online.

Today most retailers also sell their goods directly to consumers online. Most users book and purchase their air travel online directly through the airline’s site or through a reseller’s site. And nearly all financial services companies let their customers manage assets and trade directly via real-time financial sites.

I don’t need to tell anyone that reads these articles how fundamentally the Internet has transformed businesses.

However, many of these companies are trying to manage this new customer-facing internet software as if it were their internal-facing IT software, and the result is that many of these companies provide terrible online customer experiences, and worse, they don’t have the organization, people or processes in place to improve them.

I run into this often, especially when I am outside of Silicon Valley, and when I am in Europe or Asia or Australia, I find this case to be the norm. I’ll be brought into a company and they often don’t have product managers or user experience designers – they generally do have project managers, andmaybe some form of “business analyst,” and of course IT developers, and they all usually report into a CIO. Sometimes I even find that the company has been outsourcing “the website” to external agencies to design and run.

To be clear, when I say “product organization” I am referring to a software organization that creates products and services for end-customers (thousands to millions), and not just employees and partners.

Why is product software so different than IT software? Several reasons: you pay your employees to work at your company and use the software you tell them they need to use; in contrast, in product software, every user makes his own purchase decision – if they don’t want it, they won’t use it. Further, with your own employees you can get away with requiring training courses, reading manuals, and specialized professional services; in contrast, in product software, if users can’t figure out how to use your software they are a click away from your competitor. For IT software, you measure scale and simultaneous usage in the hundreds of users; in contrast, with product software, it’s in the hundreds of thousands or often millions of users. For IT software, if there is an issue with the software, they are your employees and they are forced to deal with it; for product software, an issue such as an outage disrupts revenue and immediately gets the attention of the CEO and often the press.

The truth is that most product software has a much higher bar in terms of the definition, design, implementation, testing, deployment and support than is necessary than most IT software. It’s also true that salaries usually reflect this. Finding people with the necessary product software experience is much harder than finding IT experience.

To help these IT organizations, in this article I wanted to highlight the typical changes that are needed to evolve an IT organization to an effective software product organization.

1) First draw a clear line between customer-facing software and internal software. The demands are different, the skills needed are different, and you will find you need different staff, processes and resources. Don’t get me wrong – both are important, but they are very different and most of your focus must be on your product software. If you can outsource or buy off-the-shelf any of your true IT software (internal-facing software) you should do so, so that you can put your best people, time and mind-share on the customer-facing software.

2) You will need product managers to represent the needs of your target users and lead the product discovery effort. You probably already have project managers, but if not, you’ll need project managers too, just don’t make the mistake of trying to hire one person to cover project management and product management.

3) You will need user experience designers, especially interaction designers, because designing software that doesn’t require hand-holding or a training course is hard.

4) You will need to hire engineers and web developers that understand the demands of large-scale, highly available software, and how it is different than “enterprise software.” While you may yourself be an “enterprise,” that term is referring to your IT organization and not your product organization, where you are trying to create something very different and much harder.

5) You will need QA engineers, because you will need to ensure that your software runs in the range of user environments, and under load, and outages that stop revenue from coming in are much worse than those that slow down your own employees.

6) You will need site operations staff including site security because keeping your site operational 7x24x365 is very difficult and requires special skills and processes.

7) You will likely need to revisit your software development processes from planning through to launch, as the needs of product software are so different from IT software.

8) You will need an online marketing organization. Getting people to your site is not easy in today’s search-engine-driven world, and this is a competency that many IT organizations have not realized they needed.

9) You will need to reprioritize your efforts around the fact that this customer-facing experience that allows users to directly engage to buy or use the products or services of your company is not something superficial – it needs to become a core competency of your company. This is not something to pass off to external agencies.

10) Determine your key business metrics, instrument your site, study the daily reports religiously, and then drive relentlessly to improve the key metrics.

If you don’t yet know what any of the roles or processes I referred to are, you can find out about each of these from the articles at www.svpg.com/articles.

A note of warning: there is a very large, established and lucrative industry around assisting IT organizations (especially professional services companies and agencies). Unfortunately, most of these organizations don’t understand the differences for product software either, which just causes this problem to perpetuate. In fairness, the vast majority of software out there is still custom, IT software, and these firms can help greatly in creating that software. But product software is a different animal entirely, so keep that in mind when talking to these firms.

For many companies establishing a true product software competency is the most important thing for them to be doing to ensure their survival, yet surprisingly some of them don’t even realize they have the problem. They assume that “software is software” and the same guys that managed their SAP implementation for them shouldn’t have too much trouble getting something going on the web. If you are at one of these companies, hopefully you can encourage your management to consider the ten steps above and see if you can’t get things to improve.

Email to a friend

Sign up for the free newsletter here.

Recently I spoke with a team of very frustrated Scrum engineers. They were frustrated because they felt like all they were doing for the past year was chasing features and that the product manager really had no clue where they were heading or what they were really trying to accomplish. When I spoke to the product manager (product owner in Scrum lingo), he explained that he thought the whole idea of Agile methods like Scrum was to remain flexible and “agile” and that he didn’t think he was supposed to worry about or lock in a longer-term direction.

This is not the first time I’ve seen this confusion, and I fear that creating an effective product strategy may have become an unintended casualty of the move to Agile methods.

So I thought it would be useful to discuss what a product strategy is, why it is critically important to do, and how it is actually completely compatible with an Agile philosophy.

First, a product strategy is meant to describe the vision of what you are trying to accomplish. Usually the timeframe is between two and five years out. It is a visionary work and meant to be persuasive. It is definitely not a spec in any sense.

Sometimes the product strategy is articulated in the form of a web page on a project Wiki, sometimes it’s a white paper, sometimes it’s a PowerPoint deck, and sometimes it’s in the form of a video of you evangelizing the vision. Partly the medium depends on how many people you need to communicate your product strategy to, and whether you can do so in person or whether it must be self-contained. In any case, it should be clear, compelling and inspiring. How will things be better when this product or service reaches its potential? It’s not about the specific features or functionality that may or may not be built, but rather the benefits of having this product. What problems will be solved with this product? Why will users love this product? How will the world be better once this vision is reality?

Second, the product strategy is the bridge between the business strategy and the product roadmap. The product strategy must support the business strategy, and the product roadmap is what describes your current plan of how you will get from where you are today, to the vision described in your product strategy.

Make sure you don’t confuse the business strategy with the product strategy. The business strategy might be something like “expand our e-commerce offering to allow buyers in Europe and Asia.” The product strategy might then describe the eventual e-commerce offering that has the necessary language support, currency conversions, payment methods, shipping and fulfillment methods, customs controls, etc. that you would need to support this business strategy.

Third, coming up with a good product strategy is one of the most important things a product manager (or very often, the director of product management) does. It’s not easy but without it you have little hope of actually ending up with something worthwhile. It’s like the old saying that if you don’t know where you’re going, any path will do.

We come up with a product strategy by first gaining a deep understanding of our target users, the market, and the underlying technologies. There will be brainstorming and lots of debate. You should actively involve your lead designers and lead engineers in this discussion, as well as key stakeholders. The product strategy is something that you will discuss and review actively with your management. Your executive team should care deeply about this product strategy.

Many product managers make the mistake of believing that the product strategy must come down from above, and in some cases it does, especially if you’re in a startup with a founder serving as the product visionary. But if not, you need to propose the product strategy and offer it up to your management for their review. This is a great opportunity for you to step up.

But defining and building features without a well thought out product strategy is very likely a waste of time and money.

Fourth, it is essential to understand that the product strategy does not lock you into any particular features or sequencing. Features and sequencing are represented in the product roadmap (the backlog in Scrum lingo). You can, and absolutely should, adjust the roadmap constantly based on what you learn from your users, the market, your analytics, and the ever-changing technologies we build upon.

Finally, I have found that creating a set of product principles that accompany the product strategy will help you and the product team to make the many decisions and trade-offs that arise when you actually define the features and the user experience. The product principles go along with and support the product strategy. You can read more about product principles at http://www.svpg.com/blog/files/product_manifesto.html.

Hopefully you can see that the notion of having a vision of what you are trying to accomplish is not in any sense inconsistent with the principles of Agile methods. I argue in fact that Agile methods, applied properly, will help you make your product strategy a reality significantly faster than conventional methods.

If you don’t have a product strategy for your product, I strongly suggest you take a breath, step back and ask yourself what you’re trying to accomplish? In three years or so, what do you want this product to be? How will you measure or recognize this state? Then share this vision with your management and with your product team – especially your engineers. They want to know where the product is heading too. It will help keep them motivated, they will have some faith that you as product manager are not just shooting from the hip, and also the strategy is important because it helps the engineers anticipate future capabilities and requirements which may impact the choices they make on technology and architecture.

Email to a friend

Sign up for the free newsletter here.

The job of the product manager is to define the products that the product development organization will build. Even with the greatest product ideas, if you can’t build and launch your service, it remains just an idea. So your relationship with the product development organization is all important.

I thought I would discuss in this article the leader of the product development organization. I wrote this piece together with my partner Chuck Geiger, as he has run several world-class product organizations. I have often said that if as product manager you have a good working relationship with your product development counterpart, then this is a great job. If you don’t, you’re in for some very tough days. So in the spirit of developing a better appreciation for what makes a great product development organization, we offer this summary.

First, let’s be clear which organization we’re referring to. This is the organization responsible for architecture, engineering, QA, site operations, site security, release management, and usually project management. This group is responsible for building and running the company’s products and services.

The titles vary, but often include VP Product Development, or CTO. For startups, the title is often simply VP Engineering, but as companies get larger, the focus is not solely on engineering and expands to product development and technology overall. In this article, we’ll refer to the head of this product development organization as the CTO – chief technology officer, but feel free to substitute the term your company uses.

There are five major responsibilities of a CTO. We present them here in priority order, and discuss how each is typically measured:

Organization

Build an excellent organization, with a strong management team committed to developing the skills of your employees. We typically measure effectiveness here by looking at development plans for all of the employees, the retention rate, and the evaluation of the managers and the overall product organization by the rest of the company.

Delivery

Make sure this organization can rapidly, reliably and repeatedly deliver quality product to market. There are several measures of delivery, including some measure of the quantity of work delivered, the consistency and frequency of release vehicles, and the quality/reliability of the delivered/launched software. Some organizations just look at reliability here, but productivity in the sense of quantity and quality is the real key.

Architecture

Make sure the company has an architecture necessary to deliver the functionality, scalability and performance it needs to in order to compete and thrive. The measures for architecture will vary based on your business, but in general we look to track and measure headroom/infrastructure work, and measure site outages due to architectural issues.

Discovery

Make sure that the architecture and senior engineering staff are participating actively, and contributing significantly, throughout product discovery. If your engineers and architects are only being used to write software then you are only getting a fraction of the value from them you should be. We suggest you track the participation of the product development/technology organization in product discovery (both duration and coverage), and the number of innovations that are credited to the engineering/architecture participant. It is also useful, although a little sensitive, to track changes to schedule post-discovery (churn), as you are always trying to reduce churn.

Evangelism

The CTO will serve as the company spokesperson for the product development/technology organization, demonstrating leadership in the community, with developers, partners and customers. This is often measured by establishing a university relations/recruitment program, and sponsoring or participating in at least two events per year in the developer community.

You may want to go to lunch with your engineering counterpart and discuss what they see as their biggest challenges and how you might be able to help from the product side. Anything you can do to help each other out will go a long way to creating a truly effective overall product organization, able to define and deliver winning products.

Email to a friend

Sign up for the free newsletter here.

One of the big advantages that startups have is that there aren’t many people.

As companies get larger (even a little bit larger), one of the very common consequences is that decisions become group activities. Stakeholders pop up
from every direction. The notion of ownership gets diluted down to consensus builder. The objective moves from coming up with something great, to coming up with something that doesn’t get you fired.

And the result very often is that product innovation largely grinds to a halt.

There is no question that in larger companies there really are many stakeholders, and they really must be taken into account, as there is much more riding on your decisions than in a startup. But many companies struggle because they don’t know how to manage the stakeholders yet still make progress and innovate.

In this note I want to spell out the technique that I use to overcome this all too common problem.

But first, the key for every product discovery effort is to identify the three key people – the product manager, the user experience lead, and the product development lead. These are the three minds that must collaborate closely to solve problems in new and useful ways.

The product manager plays the lead role and brings to the table the knowledge of the functionality required, and is responsible for making sure the product has value.

The user experience lead represents the user’s behavior and mental model, and works to ensure the result is something that users can figure out.

And the product development lead brings to the table deep knowledge about what is possible, and is responsible for ensuring that the product that is defined is something that can actually be delivered.

Lots of other people are going to want to join your little party. Once in a while you may decide to include a guest or two, but it is absolutely critical that you keep this team small. You simply won’t innovate in a large group setting. This is not just a brainstorming session. You will be working through literally hundreds of small and large decisions, and your progress will slow to a crawl if you don’t have that small group of smart, empowered people.

It also doesn’t mean that your small group doesn’t have help. You have the resources of the company available to you as you need it. The most common resources are from the user experience extended team: especially prototyping, user research, visual designer, and user testing help. But you may need to go talk to legal about a sensitive issue, or the analytics people about how something is used today, or maybe you will talk to someone in site security about something you are nervous about.

The key is that your core team is empowered. Empowered to represent the stakeholders and to make decisions. But this doesn’t mean that you are given a blank check. You will have to review your decisions with the various stakeholders and make adjustments where necessary.

This is where I need to drill down to explain what I mean.

Each of the three members of your core product discovery team represent many different stakeholders:

The product manager as the overall product owner typically represents the business owner, company executives, sales, marketing, product marketing, legal, finance and customer support.

The user experience lead is very often an interaction designer but depending on the project may come from one of the other design areas, but in any case must represent interaction design, visual design, user research, usability engineering and often content/editorial.

The product development lead is very often from the architecture team or a lead engineer, but again, depending on the project may come from one of the other areas of product development, and must represent architecture, engineering, test automation, site operations, and site security.

For this model to work, the three members of the product discovery team really do need to be entrusted to give their best efforts while keeping in mind the needs of their stakeholders. But in truth it’s not that long of a leash. Your product discovery team still need to be able to show what you have come up with and are proposing before the product is actually built. This is one of the benefits of creating a prototype. You can show this prototype to any or all of their stakeholders so that they can see the reason for the decisions and what exactly is being proposed.

Often there is still some back and forth as stakeholders balance their issues against the potential of the product, but I can only tell you that the nature of the discussion is completely different when stakeholders can see the vision in a clickable prototype versus just talked about in the abstract or in some form of paper spec.

Moving to this model does require a little bit of a leap of faith. Management and stakeholders have to be willing to entrust you to represent their interests instead of being personally involved at the level they may be used to.

But the notion of a small group of talented and motivated people has always been key to coming up with great products. It is the basic ingredients of a startup, and you need to make sure you continue this as your company grows if you want to continue to create products that matter.

Email to a friend

Sign up for the free newsletter here.

In earlier articles I’ve written about the product discovery process – discovering a product that is valuable, usable and feasible. I’ve explained that this is the primary responsibility of the product manager, and that product discovery requires a collaboration between product management, user experience design, and engineering/architects.

I want to contrast product discovery with what others have termed “market discovery.” Market discovery is all about identifying opportunities worth pursuing. Sometimes the market is obvious and well established (think cell phones, MP3 players, and weight loss diets), and at other times the market
is undiscovered, unrecognized, and/or untapped (think DVR, twitter).

I was recently at a conference (see www.gelconference.com) where the president of a very cool product company that’s not in the tech space, OXO (see www.oxo.com), talked about how they discover new markets. This company is fantastic at market discovery. For example, they have tapped into the aging baby boomer’s latent needs and have identified whole product lines of terrific products. For the most part, product discovery for them is fairly
straightforward, once they’ve recognized the opportunity. They learn a great deal by watching consumers interact with everyday products, which has
long been a favorite technique of mine as well.

I find that the market vs. product discovery lens is a useful way of looking at product companies. And it helps to dispel the myth that you can only win big by identifying new markets. For example, Apple rarely discovers new markets. Instead, their magic is in product discovery – coming up with great products to serve well-established but unmet needs. The iPod, iPhone, and Mac are all great examples. I would include Google search in this
category as well. They were nowhere close to being the first to identify
the search market, but they did a fantastic job on product discovery.

In contrast, I would argue that eBay, TiVo, and the Nintendo Wii all succeeded first with market discovery, and then they delivered on product discovery as well.

It’s worth noting that lots of companies succeed at market discovery and then fall short in product discovery. This is why the fast-follower strategy can be so effective, at least if your company is strong at product discovery. There’s nothing wrong with letting the big guys pay to develop a new market and then you come in with a product that actually delivers on the need.

I’ve got more coming on the differences between market discovery and product discovery, but I’m starting to frame discussions with these two concepts and finding that it can help make clear where the issues are and what’s required to improve an organization.

It also helps to make clear that since companies sell products, you must learn to succeed at product discovery. It doesn’t do you any good to come up with all these great opportunities and then not deliver products that meet the need
Email to a friend

Sign up for the free newsletter here.

In several earlier articles I have talked about aspects of prototypes. I’ve talked about using them as the basis for your product spec, and how to use them to test out your ideas on target users, and why I prefer high-fidelity prototypes to their lower-fidelity cousins. In this article I’d like to highlight the top 10 major benefits of prototyping, and talk about some of the mechanics of building and using prototypes.

Benefits:

1) First and foremost, a high-fidelity prototype gives you something realistic enough to try out your ideas with target users and customers before making a significant investment. This lets you discover which ideas are good and which are not, and if the product has real value, and also discover if users can figure out how to use the product.

2) Doing a high-fidelity prototype helps you - even forces you - to think through your product to a much greater degree than paper specs.

3) A high-fidelity prototype enables and encourages the type of collaboration between product manager, interaction designer, and architect/engineer that is necessary to discover a valuable, useful and feasible product.

4) A high-fidelity prototype provides the level of information necessary for accurate engineering cost estimates, early in the process when these estimates are most useful.

5) A high-fidelity prototype provides the engineers and QA organization with a rich, interactive description of the product’s intended functionality and
design to be used as a reference basis for implementation and test.

6) A high-fidelity prototype provides the rest of the organization – marketing, sales, customer service, business development, company execs – with a useful understanding of the product to come early enough in the process that they have time to do their jobs properly.

7) A high-fidelity prototype prevents the classic waterfall problem of doing design after the requirements, rather than realizing that functionality and user experience are inherently intertwined.

8) If you do a high-fidelity prototype and you test your ideas with users and you find significant problems, you will have saved your company the cost
in terms of time and money of building something that would have failed. Not to mention the opportunity cost of what the team could have been building.

9) If you do a high-fidelity prototype and validate this with target users, you will significantly reduce the time it takes for your developers to build the product both because the product is better defined, and also because you will have been forced to resolve many of the questions early that otherwise throw a wrench into development.

10) A high-fidelity prototype helps keep the focus of the team on the user experience.

Notes:

- Prototyping tools have improved dramatically over the past several years. Whether you’re building a web-based application or installed client software, there are several excellent tools. In the web space, in addition to the many good web development tool suites such as DreamWeaver, there are now at least two products that specialize in the prototyping/visualization space: Axure (www.axure.com) and iRise (www.irise.com). The key is that you use something that lets you very quickly and easily create a realistic user experience.

- Because the prototype is just representing the user experience, and not the often much more difficult to write software running on the back-end, and
because the prototype is not meant to be production quality software (reliable, maintainable, scalable, fault-tolerant), you can usually use a much less skilled resource to create the prototype. The key is that the prototyper must be very comfortable throwing away the work of the past few hours to try a new approach.

- Once the team moves from product discovery into implementation, the prototype should be version controlled and placed under change control. Any
user visible changes to the product definition need to be approved by the product manager and engineering, and reflected in the prototype. The prototype serves as the key reference and master. It is the one artifact that the product manager, designers, engineers and QA use to reflect decisions made.

- It is perfectly fine for the prototype to use simulated data. The data should be realistic and plausible but does not have to be accurate. Generally, the prototype doesn’t access any other database or remote service.

For product teams using Agile methods such as Scrum:

Some Agile practitioners argue that the team should just consider the early sprints as the working prototype. And in fact, for custom software efforts
where there really isn’t true product management and rarely user experience design, this is the essentially the best you can do. However, for product
software organizations, you can and must do better than this, for three reasons:

First, a sprint is typically far too long to wait to try out an idea—an idea which will most likely be wrong. It is much faster to try that idea out with a disposable prototype in days rather than wait months for one or more sprint cycles.

Second, there are typically too many critical things for the engineering team to do to use them for the product discovery process. By taking their time for this prototyping work they are not able to do what they should be doing—building production software.

Third, while Agile methods do much to encourage the team to learn and respond quickly, it is still difficult and time consuming for a team to change directions significantly once they have begun down a path, and put long hours into a particular architecture or approach.

If you haven’t yet tried creating a high-fidelity prototype as the vehicle for discovering a product that is valuable, usable and feasible, I hope you’ll give it a try. It has never been easier to do so, and I find it one of the most powerful techniques for coming up with winning products.

Email to a friend

Sign up for the free newsletter here.

In earlier articles I have discussed the key roles in the product organization – product managers, project managers, interaction designers, visual designers, usability engineers, prototypers, engineers, architects, QA and product marketing – and I’ve also discussed the ratios between the roles, but many organizations also struggle with the organizational structure that contains these people.

While I have seen - and continue to see - many different permutations out there, I do think that a standard organizational structure for product organizations has emerged over the past several years, and that there are good reasons for this structure.

I will admit that I do not feel nearly as strongly about the organizational structure as I do about the roles and responsibilities. I believe that if you have the right role definitions, and reasonable and well-intentioned management, you can usually make most organizational structures work, and I have no real problem with designing an organization around the strengths of the individual leaders rather than following a template from successful product organizations.

That said, we all know that organizational structure really does impact behavior, so all things considered equal, I argue that evolving towards the structure I describe below will improve the effectiveness of your overall product organization, sometimes in very profound ways.

Please note that I am only talking here about the product organization and not the other major areas of your company including sales, customer service, finance, business development and IT (as distinct from product development).

I argue that every CEO/COO or division GM needs three clear and distinct voices on his staff: Marketing, Product Management and Design, and Product
Development. As such, the most important aspect to the organizational design is that these three be top level, and one should not be buried within another.

So, reporting to the CEO/COO of a small or medium sized company, or each business unit GM of a large company:

- Marketing contains functions including corporate marketing, marketing communications, field marketing, and product marketing.

- Product Management and Design contains product management, user experience design (interaction design/information architecture, visual design,
prototyping, user research/usability engineering), and if applicable, subject matter experts.

- Product Development contains architecture, engineering, QA, release management, site operations (for SaaS companies), and project management
(PMO).

Notes:

- Notice that IT (the technical team that supports employees) is intentionally distinct from the product development organization. This is the topic of a future article, but for now let me say that the demands on these two groups are inherently different, and that it’s important to treat each appropriately. In terms of titles, normally the CIO runs the IT organization, and the CTO/VP Product Development/VP Engineering runs the product development organization.

- In some companies, the PMO is a top-level report and this is fine. But most often it’s part of the product development organization because the
vast majority of the resources the project managers deal with are part of that organization, and this allows the head of product development to be fully empowered and accountable for product execution and delivery. In any case, it’s important that the projects managers report into the PMO.

- It is a problem if User Experience Design is buried either in marketing or product development. It is critical that the user experience team,
especially the interaction designers, be very closely tied to the product managers. Keeping product managers as close as possible to the UED team is the reason for the trend towards combining product management and design into one organization (although each should have its own leader – the
director of product management is responsible for product strategy, and the director of user experience is responsible for the site/software overall information architecture and style.

- Marketing typically also has some number of graphic designers that support marketing programs and advertising. This need might be served out of the visual design team in the user experience org, but I prefer if they are a part of the marketing organization. A strong user experience requires
constant attention not just to the interaction design, but also to the visual design of the application, and this group should be managed by someone who understands what it means to support a product team. If there is a single Creative Director who understands both visual design for product, and visual design for marketing, the company is in great shape because one visual design group can serve both needs, and the overall expression of the brand will be very consistent. But if the head of the visual design team is under marketing, and isn't understanding the needs of the product, you will need to correct this situation as soon as possible.

- User research is sometimes separate from usability engineering, which is fine. But do not confuse user research and usability research. User research is background data on the demographics of the customers, or analytics of the customer’s behavior or buying patterns. It is not unusual to find user research as part of the marketing organization, which works so long as the product managers and interaction designers have ready access and a good working relationship with the user researchers. Usability research, by contrast, is specific research on personas, prototypes, or users' ability to easily navigate the product. These researchers' work feeds directly back to the interaction designers, visual designers, and product manager, and it is critical that they be an integral part of the user experience design team, so that their efforts can be collaborative and their research windows scheduled and closely managed to get feedback quickly during product discovery.

- Sometimes product marketing is part of the product management organization. This is not a big problem, and there are some advantages to that, but I prefer when it’s part of marketing as this helps to reinforce role definition and make sure there’s no confusion between product management and product marketing. To be clear though, even if product management and product marketing are part of the same organization, the roles should not be combined.

- Startups are a bit of a special case in that they are typically small enough that the organizational structure is minor compared to the personalities and individual skill sets involved. But remember that if things do go well, you’ll grow fast, and you’ll want to put an effective organization in place sooner rather than later.

If your organization is not structured in this fashion, then if things are working great I would not suggest changing a thing. But if your team is struggling, and if it feels more painful than it should to get good products out the door, then consider evolving your organization more towards the model described here and see if that doesn’t improve the situation.

Special thanks to both Chuck Geiger and Kyrie Robinson for their contributions to this article.

Email to a friend

Sign up for the free newsletter here.

I’m not sure how many of you have heard the phrase, “we eat our own dog food,” but for several years at least, companies especially in Silicon Valley have used this phrase in order to impress their customers that their product is so good that they run their business on it and use it themselves. This was practically a mantra at Netscape, and I can’t count how many times I’ve said this myself.

Today, I’m embarrassed to have said something so meaningless. Of course we used our own products. It would have said much more about the state of our products if we couldn’t use them. And yes, of course you should use your own products, but you need to realize that it’s just another form of QA. Just as you wouldn’t brag that your software passes unit testing, you don’t need to brag that you can actually use it.

But the real issue here is not the importance of running your own software. The real issue is that this is just another symptom of a big problem we have in our industry, but especially here in the valley. We tend to believe that our customers and users are much more like ourselves than they really are.

If we like it, and we can figure it out, then others will too. The problem is that this just isn’t true. Yes, there are some niche markets like developer tools where it is somewhat true, but even there it’s less true than you may think. There are several reasons for this.

First, realize that not only do you not have to pay for your own software, but in fact you are paid to use it, as employees. It would shock me if SAP doesn’t use their own software to run their business, but it means nothing to me that they do. Their employees essentially have a blank check to make it successful. But their customers don’t. Imagine the SAP employee struggling with the product, and getting to the point where he says to his manager he wants to switch to Workday. Do you think that’s likely to happen? Of course not. But do you think this could happen at their customer’s site. It can and is happening.

Realize that your company’s employees are much more vested in your product and company than your customers, and that means you’ll tolerate more, much more than your customers.

Second, if we have a problem or a question, we can just go ask the developers. Your customers can’t. They have to read manuals, attend training classes, sit on phone calls with customer service, or sift through forums with other customers struggling through their own issues. Frustrating and time-consuming, and detracting them from whatever their real job is.

Third, a great many of us in tech companies are early adopters by nature. I know I am, and I also know that this means that what motivates me is going to be very different than what motivates target customers. This is a big reason why I like personas as a tool for calling this out.

But the bottom line is that all this points to how absolutely critical it is to test your ideas and your product on real target users and customers. If you haven’t been surprised by how different a customer’s response to your product is, then you probably haven’t yet done this type of testing.

Remember also that when you do this testing, it’s not enough just to get your product to the point where the user can figure out how to use it. You also have to get the product to the point where the user chooses to use it.

Email to a friend

Sign up for the free newsletter here.

In the last article I talked about the role of architects and engineers in the product discovery process. I explained that great products come from the collaboration of the product manager, user experience designer and architect/engineer.

I often get approached by current engineers asking what’s involved in moving to product management.

Sometimes this happens when the engineer gets to truly participate in the discovery process, and he gets a taste of actually influencing what the product is and not just helping to build it. And sometimes this desire to move to product management comes from the frustration of realizing that it doesn’t matter how good the engineering team is if they’re not given something worthwhile to build.

In any case, many of the very best product managers I have ever known have come from engineering, and in this article I’d like to call out what I’ve found to be the main challenges for engineers as they make this move.

Realize that engineers have a big advantage in that they generally have a deep understanding of what’s just now possible. If they can now combine this with a deep knowledge of the user, and develop some new skills, you’ve got the makings of a great product manager and great products can result.

First, and most important, you have to realize that you are nothing like your target user. If you spend the time you need to with real users you’ll
quickly learn this, but you need to disabuse yourself of any notion that if you like the product and can figure out how to use it, then your users will like the product and figure out how to use it.

Second, and related to the above, you need to develop an empathy for your end-users and customers. You need to realize that they’re not clueless, but that they have their own jobs and own areas of expertise, and they are as busy as you are but with their own lives, which are typically very different from yours. The easiest way to achieve this is to spend actual face time with your users and customers. Note that this doesn’t mean that they have any idea what they want from your product or what the real product requirements are; it’s your job to figure that out.

Third, there is an important mind-set change that needs to happen. In an engineering organization, especially if you’re a lead or manager of engineers, you are always working hard to optimize your developer’s productivity. This is important, but as product manager you must now realize that your job is not to optimize the developer’s productivity, but rather to optimize the end-user experience. It is no longer about coming up with the fastest way to build something, but rather coming up with a product and user experience that users actually value and can figure out how to use. While this might sound easy, I promise you that when you’re faced with hard decisions and time versus user experience trade-offs, you’ll have to fight your natural tendency hard.

Fourth, you’ll need to develop a humility that comes from showing your ideas to users and customers and finding that in many cases users don’t respond the way you hope. But you will learn that if you listen and watch closely, you’ll improve your understanding and if you keep trying, you’ll likely get better fast. But this only happens if you’re open to learning and can handle the rejection.

Fifth, there is a culture among engineers that values active debate and sometimes loud and passionate arguments, but in many cases the decisions are
fairly clear as one solution is objectively better – runs faster, scales better, more fault tolerant, more extensible, etc. The point is that technical decisions often have a clarity and closure about them that doesn’t always exist in decisions around product definition and user experience. You may find that you need to modify your style of persuasion and argument, and work harder to build support for your opinions and decisions.

Finally, your relationship with your old engineering team can be a difficult one. They may soon come to challenge you in ways they may not have before. They will doubt your ability to stay on top of the technology, and they’ll be sensitive to you speaking for them or especially committing to things on their behalf. You will need to learn to bite your tongue and let the engineering team do their job and participate with you in discovery. But you should have enough to worry about with the overall product responsibility that you shouldn’t mind letting go of the technical decisions.

I strongly encourage companies to facilitate this type of career move. You can often end up with some truly outstanding product managers. At the least, even if the engineer decides to go back to engineering, he’ll have gained a level of customer insight that will help him do his job even better.

A special thanks to Steve McClelland for his insights into this transition. Steve is a terrific example of a talented and valuable architect becoming an even more valuable product manager.

Email to a friend

Sign up for the free newsletter here.

The job of the product manager is first and foremost to discover a product that is valuable, usable and feasible. You’re wasting the rest of your team’s time, and your company’s money, if you can’t do this. But this doesn’t mean that you have to discover this product yourself.

There are, in general, two other key roles besides yours. In other articles I have written about the critical role that a user experience designer (aka interaction designer) plays. In this article, I’d like to talk more about how and why you need to include the engineering organization in this discovery process.

First a terminology note. When I refer to “architect” in this article, I am referring to an engineering or systems architect. I’m not referring to an information architect (which is similar to an interaction designer and is part of the user experience team). Also, I use engineer and developer interchangeably.

There are actually two topics when discussing the architect role. The first is to discuss why and how to have architects participate in the discovery process. The second is to elaborate on this relatively new role within product development that has several benefits to the product organization.

Participating in Product Discovery

One of the most common mistakes that product managers make is to not include engineering early enough to make a difference. By the time engineering is often brought in, you are so far down a path that time is running out and there’s little that can be done. Sometimes this happens because the product manager believes it’s his job to define the product, and it’s engineering’s job to build it. Sometimes this happens because engineering is so busy building that they can’t free up any resources to participate earlier.

There are really two main reasons you need strong representation and active participation by the engineering organization during the product discovery process:

- First, the engineers and architects know best what is possible. They can help identify new solutions to user’s problems. They can contribute ideas, evaluate ideas, and improve on ideas. They are an absolutely essential ingredient to the product discovery process.

- Second, the engineers and architects can evaluate the cost and complexity of the different ideas and features. They can review prototypes, and help flesh out what is involved with each idea. It is essential that these time and cost estimates are provided early, during the discovery process, as this is key information for the product manager to decide whether or not a feature or capability is worth including in the resulting product definition.

The idea is to avoid the common problem where the product manager comes up with a great product, and then hands it off to engineering where they estimate the cost, and of course it turns out to be far too long to build, so the horse trading begins when it is too late to come up with good alternatives and test them with users; and more generally the problem of the product manager coming up with great ideas that are simply not feasible.

In terms of the engineering time required for this participation during product discovery, I typically tell engineering and architects that they need to plan for a few hours a week to review the latest ideas and prototypes and provide the necessary feedback. As product ideas progress, they’ll be asked to give more than just preliminary advice on cost and scoping, and at that point they’ll need to dig in more and provide estimates that the team can count on as they make the critical trade-offs.

The Architect Role in Product Development

As products and teams get larger, especially for large consumer internet sites or consumer electronics devices, the product development organization needs people that have a holistic view of the complete product. These people know not just one or two areas, but they are responsible for knowing, at least at a high level, how the whole product works including architecture, site operations considerations (including scale, performance, and provisioning) and topics such as test automation and release management. Increasingly I am seeing companies establish a centralized architecture team to develop these people, and I think this is an important trend, for several reasons:

- The architecture of large systems needs constant attention to ensure the system can continue to meet the needs of the business. This includes worrying about site availability, scalability, performance, maintainability and internationalization, as a few examples. The architecture team is always looking for bottlenecks and inefficiencies in the system, and they typically provide prioritization, guidance and assistance on the different areas needing attention.

- The architecture organization is an additional contributor to the overall Portfolio Roadmap. They are the owner of Technology Sponsored Initiatives, and often will debate with other parts of the business for precious engineering resources. The architecture and systems engineering activities need to be prioritized against other business initiatives, as it's not always sufficient to use the small, dedicated group of system engineers and architects to do everything that must be done.

- It is important that your top engineers not feel that they have to move into management to progress in their career financially or professionally. The dual track serves this need well, and the architects are typically the top of the engineering ladder as an architect job is valued by the organization at all levels.

- The truth is that most product engineering teams today don’t maintain internal system documentation. They may have something written down but it’s probably old and nobody trusts that it’s accurate. So when new engineers start, they generally learn by talking to other engineers. The architects represent the institutional knowledge (living documentation) of the system, and they are responsible for helping new engineers learn the architecture and code base.

- One common and effective technique to ensure new work is compatible with the overall architecture is for the architects to attend all of the code and design reviews. This also helps the architects stay current, but the primary benefit is to detect and prevent problems in the code and architecture.

- The architects also are resources to help evaluate 3rd party integrations and participate in M&A due diligence.

If you organization is small, your architect will likely just be one of the senior developers. But as your organization grows, a designated architecture team can make a big difference. As a general rule, architecture teams generally represent roughly 5 percent of the engineering organization. Ideally, there is also someone from site operations on the architecture team, especially as companies come to appreciate how difficult the site operations considerations can often be when it comes to keeping a large and complex site up and running.

Whether you promote your architects from among your senior engineers, or whether you hire architects from the outside, it’s important that the architects have the trust and respect of the engineering team. The architect is in an important sense representing the engineering team, and when they say something is feasible the team needs to know that was an informed statement.

As a product manager embarking on a new project, your first task is typically to identify the user experience designer and the engineer or architect that you’ll be able to work closely with throughout the product discovery process so that you can work together to identify a product that is valuable, usable and feasible.

If you’ve never had a chance to collaborate like this on the creation of a product spec, I promise you that you will much prefer this process to the old model of writing PRD’s and asking engineering to review and provide a schedule. You’ll also very likely see a dramatic improvement in the quality of the products you come up with.

Email to a friend

Sign up for the free newsletter here.

I find that many companies remain stuck in old, failed models of product management, and don’t always realize how important role definition is to building effective teams and successful products.

In several articles I’ve tried to explain what the role of the product manager is really all about, but in this article, I’d like to come at this from another angle and try to emphasize what the job is NOT. I’m hoping that calling out these misunderstandings will help companies realize where they have issues and hopefully revisit how they are defining this role.

- Product Management is not defining the business case

Some product managers believe their job is simply to define the business case for why this product should be built. Is the business case important?
Of course. Mainly because management will use this to make decisions on where to invest. But this doesn’t really do anything to contribute to actually creating the product. In many organizations the product manager does put the business case together, or at least contributes to creating the case, and this is fine, but don’t confuse this with the product management job.

- Product Management is not defining market requirements

For many companies, they think the product manager defines the market requirements and the engineers build a product to meet those market needs. The product manager creates an MRD (Market Requirements Document) that enumerates what the product manager thinks the market is looking for, and then actually defining the product that meets these requirements is an exercise left to the reader (which is typically an engineer). There are really two issues here.

The first is the fallacy of so-called “market requirements.” Markets don’t have requirements. People do. And the person that’s actually going to be defining this product has got to talk to these people directly. If the engineer is the one defining the product, then that person is the true product manager and you can only hope he understands that as the product manager he needs direct face-time with actual users and customers.

The second issue is the fallacy of market requirements separate from product requirements. The whole idea is to discover a product-market fit and this requires a deep understanding of both the market needs and the technology’s capabilities. It is during the discovery process that you identify true market requirements and technical solutions that successfully address these requirements.

- Product Management is not requirements gathering

Many companies, especially those with a direct sales organization, have the model where the job of the product manager is to gather up the requirements from the customers or prospective customers, document them for engineering, and then make sure those requirements are delivered by the dates the sales guys promised the customer.

This is not product management. This is project management for custom software solutions. True product companies know that customers have issues that need to be addressed, but they are not in a position to dictate the product requirements. In other words, you can’t make the mistake of confusing a customer requirement with a product requirement.

Be wary of anything that encourages this “requirements capture” or “requirements management” mentality. It is a very slippery slope and one of the surest paths to failed products.

- Product Management is not project management

In some companies, the product management group was borne out of the project/program management organization, especially when the company has an IT or custom software heritage. In this model, the product manager is considered the person to collect and document the requirements, and manage the project from conception to delivery. But the discovery process is not simply a task in a project plan. It is its own process, which is very different than the product development process. Moreover, rarely do you find individuals that like both product management (discovery) and project
management (delivery) as the nature of each type of person is so different.

- Product Management is not product marketing

Finally, product management is not about pricing, promotions, positioning and messaging, or product launch activities. Nor is it about online marketing and customer acquisition strategies or influencer marketing programs. These are all critically important activities, and the product manager will provide input to many of these activities, but don’t confuse them with product management. These are product marketing activities, and for all but the smallest products, you are going to need a skilled marketing person dedicated to this. While the company might be tempted to ask the product manager to cover these responsibilities as well, realize that the nature of these marketing-based activities is dramatically different than the discovery-based activities, and it’s very hard to find people that are skilled at both.

In contrast to the above, the product manager is responsible for discovering a product that is useful, usable and feasible. If he can do this, he’s done his job. If he can’t, there’s no point in spending the time and money to build and launch the product.

If your company makes any of the mistakes above, pass this note on to your management. Ask if perhaps you could try adjusting the role on your next product to see what happens. I think you’ll find that if you can focus on discovery, you’ll get a chance to show your company what product management is really all about.

Email to a friend

Sign up for the free newsletter here.

By Martina Lauchengco

No one coming to your website? Company image tired? Business plans changed? It's time for a rebrand!

Or maybe not.

Somehow "brand" became magic pixie dust to sprinkle on company problems and make them go away. But you can't create or fix a company with just a name, logo and color palette. Anyone remember Webvan's "rebrand" into oblivion? In technology, we tend to think we're the exception to all the rules. The problem is most don't know the rules, which means brands don't do what tech companies expect.

What's the problem? A true brand is much more than a company's name, visual identity, or how much it advertises. A brand is a promise to customers that transcends any individual product or service. The best brands are built on a foundation of a simple product or service provided consistently. Cheap food fast? McDonalds. Mid-afternoon coffee boost? Starbucks. Need help finding the perfect tie for your suit? Nordstroms. Coolest new tech gadgets around? Apple. Need it overnight? FedEx.

Now quick--Do you know how many logos these companies have gone through in the last five years? My guess is no, and you probably don't care. This is the power of brand done right and also why creating one is so much harder than people think.

Many high-tech brands start like this: the powers-that-be get together for a "brand brainstorm," come up with a list of rational brand attributes like 'smart' and 'innovative,' put it in a PowerPoint presentation, hand it over to an agency that charges a small fortune to create a name and a logo the founders like, and viola a new brand is born. For most companies, the brand experience begins and ends there.

And that's the problem. Great brands are powerful because their relationship to us is emotional, not just rational. More importantly, they come from the systematic delivery against every aspect of the 4Ps, starting with products (or services). Genuine connections with customers can't simply be brainstormed into a company mission statement. If your product or service doesn't fulfill your brand promise, your name and logo don't matter. Think about most of the newest generation of "breakout" online brands--YouTube, Facebook, FlickR, MySpace. They didn't succeed because they spend millions on advertising or had great logos. They delivered a consistent product experience. The same holds true for the major online brands that preceded them: Google = search, Amazon = buy online, eBay = buy/sell peoples' stuff.

A brand isn't any one thing; it is the collection of all the ways a company touches its customers--on the web, in advertising, in PR, in sales, in retail, and the products themselves--that create or reinforce a brand. This is why new logos and names don't solve company problems; they usually aren't the problem.

So if you're a relatively new brand aspiring to become one of the great ones, what do you do?

1. Start with your product/service.

In technology, you can't have a great brand if your product or service isn't. This doesn't necessarily mean it has to be the most amazing product on the planet-just that what it is and does must be easy to understand, consistent in its presentation, and serve a need people remember or value. It's easy to look at a company like Netflix and say, "Everyone knows the red envelope. It's a brilliant brand." But it's their rich service that made the brand ubiquitous and successful.

2. Be consistent.

After having a good product, this is the single most important thing you can do, and it doesn't take extra money, just discipline. Anything that touches the customer is part of the brand and either reinforces what you want the customer to believe or makes you look untrustworthy. This is the one of the biggest failings of technology companies; they stop at the colors and logo being on everything and fail to ensure all aspects of content and product support the brand.

Apple's recent iPhone pricing debacle is an example. Strategically, a high price point at launch was a shrewd business decision--it limited distribution while they ironed out bugs and instantly gave early adopters the show-and-tell goodie of the decade. But when Apple dropped the price so quickly for essentially the same phone, it sent their fiercely loyal customers into an uproar. It made Apple look like they were exploiting their most loyal fans which is totally inconsistent with Apple's "power-to-the-people," populist brand. To Apple's credit, they immediately addressed the problem.

3. Look at the customer's entire experience.

Everything that touches a customer needs to embody a brand for a 'brand effect' to occur. From language, to look and feel, to how people behave-even dress-it all has an impact. One enterprise startup I know defined a key brand attribute as "leadership," and they worked hard to ensure everything they did validated it. Their initial target customer list was Fortune 100 only so their customers' brands could reinforce their leadership claims. Their employees also dressed in formal business wear when visiting a customer. They were told in competitive sales situations, they out-classed their competition, and this perception was reinforced by how everyone dressed. They behaved like leaders, even when they weren't. Of course they had the products to back up the brand, but it all created a brand effect and momentum that helped them become an undisputed category leader over time.

Again, Apple is the king in technology of using the customer's entire experience to reinforce their brand, from the elegant, hip packaging, to the lack of documentation, to the "geniuses" in the Genius Bar in Apple Stores-the very fact that they have a store-their advertising, and of course, their consistently stunning products.

4. Don't underestimate the power of people, pictures and music.

This is the easiest way to move something from rational to emotional. Those "Priceless" Mastercard ads have milked this to an extreme. VW uses music brilliantly in all their ads; BMW did an entire movie short series with A-list talent. But you don't need to spend millions on TV or film ads to infuse emotion into your brand. People connect with people. Think about where you can humanize your brand experience-such as putting the picture of a tech support or sales person on your website saying "Talk to me live now!" Real people/customer quotes is another example. Having a real customer pick up the phone and call a potential customer is a powerful brand statement. And certainly if you have a direct sales force, they are your foremost brand emissaries.

5. Separate company brand from product and service names.

Many technology companies put their brand investment behind individual products or name the company the same as the product. This can be a fine start but make sure you adapt quickly if your business/products do. The difference is as simple as Oracle Database 11 instead of Oracle 11 or Yahoo! Search instead of just Yahoo! This type of brand strategy is called a "master brand" strategy and means 1) you invest in your company's brand meaning, not your individual products 2) because the company name carries the consumer promise, it precedes every product or service name. It's the most common brand and naming strategy used in technology where products change quickly.

Too often technology companies don't make these distinctions fast enough. Not only does this make things confusing to customers, it can put your business in a corner that is very hard to fight out of. Think about how many years, millions of dollars, and acquisitions it took Oracle to get beyond being just a database company. One of my alma maters, Netscape, never defined the brand beyond the browser, so when the browser was in decline, the entire company was perceived to be in decline. Don't make this mistake.

6. Be patient-stay steady.

Building a brand takes a lot longer than you might wish, even when you employ the best techniques and everything is going great. It's true some brands reach mass market recognition faster than others, but even the fastest take years before they reach mass consumer awareness. The more a company's brand elements change in that period, the less a consumer has to hold on to and understand exactly what the company is about. Consider that each time some part of the brand experience changes, you're starting over with some customers. And if the ultimate goal of brand is to short-cut decision-making, changes at the brand level take that potential away.

7. New brands are okay for the right reasons.

If your market penetration is knowingly impeded by your existing brand's baggage, then it makes sense to opt for change. My favorite example is Microsoft's Xbox. They needed a new brand for gamers that shed the Microsoft baggage because, let's face it, they just didn't have street cred with gamers. Halo 3 is also marketed as its own brand, not as Microsoft Halo. It took Microsoft over a decade of trying with "Microsoft Home" and various other brand extensions before they finally took the plunge with a new brand. No doubt this was a battle with the corporate brand police, but ultimately, it was necessary for the product line and brand to succeed.

Great brands engender loyalty beyond reason - because an emotional attachment and consistent experience provide a short-cut for decision-making. Ultimately, brands are about trust-which is hard to gain and easy to lose. So when it comes to brands, take time to think about all aspects of your brand so it can help your company achieve its goals.

Email to a friend

Sign up for the free newsletter here.

In a recent article (The Best Product Management Model) I discussed the notion that there is no single best product management model, and that the most effective model for a given company depends on a wide range of factors. I received several comments from people asking me to explain more about these factors and their consequences. To cover this I’m going to need a series of several articles, but I thought I’d start with the factors that are most often driving the need for improvement in the first place.

When I typically begin working with a company to help them develop the skills of their product organization, and the techniques to help them become more effective at producing successful products, I begin by asking about the specific challenges they face.

Here’s a list of the top 10 most frequent complaints I find at high-tech companies:

1. Wasted Release Cycles. Probably the single most common frustration that senior management (as well as engineering) has is the feeling that they all work hard but at the end of the year they have little to show for it. They may be Agile and may have released a boatload of new features, but they have very little in terms of results to show for it. More generally, there is the feeling that many releases, often a majority of releases, are wasted cycles in that they fails to meet their objectives. Sometimes things even get worse.

2. Time to Market. Right behind wasted release cycles is the belief that it takes far too long to get from initial concept to successful product. Not simply the time for a release, but rather the total time including however many follow-on releases are necessary to get the product to the point that
it accomplishes what it was originally supposed to do. Even with Scrum teams, they might have an average of 3 or 4 sprints per release, but they
find they need at least three releases to start making any money. All told it’s easy to see how “time to money” can easily be measured in years and not months.

3. Lack of Innovation. Especially in larger companies, but even in startups that hit the year-mark, there is often a feeling that the company has somehow lost the ability to innovate. Yes, they had some great early innovation, but then things seemed to get much harder, and everything that’s done feels like it’s at the margin and not really making an impact, even though the staff is larger than ever.

4. Unhappy Customers. Few consumer-facing companies survive long with unhappy customers (there’s a self-correcting mechanism built right in), but for many business software companies, they can continue for quite some time with unhappy customers, especially since switching costs are often very high, combined with the fact that often the people that make the purchase decision have little to do with those that use and depend on the product. But companies with serious customer satisfaction issues are no fun for anyone.

5. Replicating Success. Many companies out there had one good product at their start, and then struggle for years to replicate that success. The best they can do is refine the original product, but eventually all product cycles play out, and management becomes increasingly concerned about the lack of future revenue streams.

6. Handling Growth. A good problem to have, but one that’s very difficult nevertheless, is when your company grows very rapidly, and what worked for you before no longer scales. Managing through rapid growth is a very real challenge for successful companies, and everyone knows the stories of companies that wasted away fantastic opportunities by not effectively adapting to the new demands.

7. Specials. In many companies, especially large enterprise companies, they get seduced by the promise of a big customer in exchange for “special” features. It only takes a few of these before the organization is so bogged down with customer-specific requirements that even the smallest changes take a long time, and then on top of that they can’t seem to get companies to buy the “standard” product.

8. Decision Making. In far too many organizations the decision making process is broken. The product team can’t get decisions made in a timely manner, and when they are made, they don’t stick long enough to get a product shipped. A very related complaint is churn, which is when requirements change so frequently during development that it’s very hard to make forward progress.

9. Role Confusion. In many companies, there is no clarity around who “owns” the product, and who is responsible for each type of decision, and lack of understanding of the purpose of certain roles. The result is that there’s no real sense of ownership or accountability.

10. Employee Morale. Finally, I’ll often get called into product organizations because of low employee morale. The company isn’t able to retain their best product people and nobody’s happy about that. Of course this is just a symptom and is likely the result of several of the items above, or other factors such as role definition, or very often company culture.

Now each of these is a symptom of underlying problems in how the company produces products. While there are specific techniques that can be used to help some of these, the most effective product management model is the one that will not only address the symptoms but work to institutionalize the appropriate behaviors and processes.

More about additional factors in upcoming articles, but if you recognize any of these symptoms you might want to take a hard look at how you create software and ask yourself if how you handle product management may have anything to do with it.

Email to a friend

Sign up for the free newsletter here.

Contributed by Marty Abbott

From the “C”-suite offices to the product manager’s desk, everyone seems to be frustrated with time to market as measured from the initial idea to the launch of the product. At one level, the frustration is understandable as nearly every organization has something they can do to improve time to market.

That said, unrealistic expectations stemming from a frustration over why things can’t happen overnight is an all too common problem that can be damaging to an organization. Unrealistic expectations can cause low morale and frustrations that ultimately lead to employee turnover, delays in product schedules and lost opportunities.

In our experience the problem behind unrealistic expectations often stems from a limited understanding of the product development process, and the misguided notion that the combined phases of product discovery, product engineering and product release should somehow take less time than the time it took to generate the initial idea: “I explained my idea three weeks ago. Where is the product and when do we launch?” This notion often isn’t stated out loud and if discussed in a group it even sounds ludicrous, but it exists nonetheless in the minds of many C level executives.

Good ideas are extremely valuable, and yours might be so brilliant that it creates significant strategic differentiation; creating barriers to entry for competitors and prohibitive switching costs for customers thinking of moving from your products. Your idea may be the result of endless hours of analysis and insight – but you must recognize that your idea and the desire to implement it is a form of demand generation for services from your product and engineering teams.

This “demand” generation is akin to deciding that you want to build a house with certain amenities. While we all understand that it takes time to build a house when considering the discovery phase (is our house feasible on the plot of land and with the local regulations, and is there a builder who can build it to our expectations?), architectural phase (a combination of designing the house and planning for the construction) and building phase (the engineering or construction of the house), we somehow have a hard time understanding that these concepts apply to your products and services as well.

None of this is meant as an excuse to have low standards, or a reason to not hold your team to an aggressive schedule of shareholder wealth creation. In fact, we argue for just the opposite. But understanding that even the most brilliant of ideas costs much less in time and money to “ideate” than to explore, specify, implement and deploy in systems and software is a good step towards creating aggressive yet realistic targets.

Ask for detailed plans and question the details until you are comfortable. Drive to the earliest possible date, but create that date from good analysis and good planning, and drive and challenge your team to create the best possible date from good data. Remember – if your idea can be implemented overnight, it can probably be copied in 2 nights by your competitors. True value creation can take time.

Email to a friend

Sign up for the free newsletter here.

I’ve written earlier about how much domain experience is important for product managers (The Role of Domain Experience) and also the pros and cons of college hires versus hiring experience (Youth vs. Experience), but a question I often get is just how much technological competency is required in order to be a strong, effective product manager? Many managers aren’t really sure if a candidate is technical enough, and many aspiring product managers aren’t sure if they are technical enough for the job.

This is an especially relevant topic right now because the current industry flagship, Google, is famous for having a very high technology bar for product managers. Google is a bit of a special case, so I’ll come back to them in a bit, but I think this is not only a fair question, it’s critically important question.

First a necessary disclaimer. I think you’ll find the opinions on this topic vary based on whether the person has a technical background or not. A political science undergrad from Stanford that goes on to get a Harvard MBA and move into product management may have one view, versus the computer science student turned software engineer that then moved into product management. My education was in computer science, and my career began with 10 years in software development, most of it at HP Labs, which was an extremely engineering and technology-driven culture. So there’s little question that my opinion carries some biases based on that path. That said, I think some of what you see below may surprise you.

Why Technology Competency Is Critically Important

There are two very big reasons why I believe that technology competency is absolutely critical to being an effective product manager.

First, I have long argued that great products result when you combine a real need or problem with something that is just now possible. The technology competency is what allows you to understand and identify what’s just now
possible and how it can solve your problem in a new or better way. I argue that this ability to quickly grok and apply new technologies to solve problems is at the core of great products and great product management.

Second, while I believe it is absolutely true that it doesn’t matter how great your engineering team is if the product manager doesn’t provide them something useful to build, it’s equally true that without the engineering team to build the product, you have nothing. So you absolutely must work effectively with your engineering team. You have to be able to speak their language, understand and appreciate their issues, gain their respect, and be a capable partner in the collaboration that’s necessary for any product.

When I interview product management candidates, I’m looking hard at these two points. The candidate must convince me that they are capable of understanding and applying new technology, and of earning the respect of the engineering team.

That said...

Why Technology Competency is Often Overrated

While I believe in every word above, I also think that in general the technology competency requirement is often overrated, again for two big reasons.

First, for most products, it’s all about the user experience. It’s really not about the technology used to build or scale the product, it’s about providing a user experience that users want to use, and can figure out how to use. This speaks to a design competency more than a technology competency. The most excellent book, “The Inmates Are Running The Asylum” by Alan Cooper makes this point better than I can. Having a product manager that’s a great potential contributor on systems architecture, but whose eyes glaze over when the discussion turns to information architecture is not useful.

Second, one thing I absolutely love about the Internet era is that for a great many types of products and services, we are typically limited more by our imagination than our technology. As an example, when I lead the product team at eBay, there were hundreds of projects during my time, but only rarely did the engineering team tell us that we couldn’t build what we wanted to. Now partly this was because there were quite a few exceptionally good engineers and architects, but I’ve seen this in many companies since. The true bottleneck in most companies is not the engineers or the technology, but rather it’s the ability of the product managers and designers to come up with something worthwhile and compelling.

What Is Technology Competency?

I realize I’ve been using this term loosely. There’s lots of “technology” that an engineering team deals with and you learn when you spend time as a developer. There’s technology topics like programming languages. Does the
product manager need to understand the pros and cons of multiple inheritance or polymorphism? Probably not. There’s technology topics having to do with team development, conflict management, and continuous and reproducible builds. Does the product manager need to understand the various forms of parallel development and the difference between configuration management and version control? Probably not.

However, when the engineering team has been unable to invest in infrastructure and the team is facing real issues in terms of scalability, availability, and maintainability, does the product need to understand and appreciate these issues and their impact on the ability to get new features
delivered? Definitely yes. And when a new technology is introduced, such as Ajax, or Silverlight, or Android, or the Facebook platform, does the product manager need to quickly understand what these technologies enable, and then come up with ways for these technologies to benefit their customers? Absolutely.

Technology Competency is when the product manager can quickly learn new and relevant technologies, not necessarily in order to code to them, but to apply them. Strengths and weaknesses, capabilities and limitations.

How do you develop your technology competency?

Just as I am constantly exhorting product managers to get out there and talk face to face with users and customers, you should also spend considerable time developing your technical competencies. There are many ways to do this. Books, articles, blogs, extension courses, experiment with the technologies or write software on your own, spend more time with your engineers, ask them about the technology topics they are exploring and tag along. Just like spending face time with users, spending time with your engineers on the technology is an ongoing responsibility. Remember that what is possible is constantly changing, literally every day in our business, so you must be passionate about pursuing this knowledge.

Some Exceptions to the Rule

So hopefully you can see that while I consider technology competency an essential requirement, I also view it as something that most people in high-tech can absolutely achieve with a some effort. All that said, there are a couple important exceptions to this.

The first exception is with certain type of products that truly do require a level of technical sophistication in order to competently define useful products. A very important and timely example of this is platform product management. Here you not only work with developers to build your product, but you also work with developers as customers and users, and typically at the level of the software itself. There are other products like this – developer tools and technologies, system infrastructure, systems software, etc.

The second important exception has to do not with the type of product, but with the culture of the company. There are a few companies that have established engineering as the basis of their culture and DNA. Today the main example of this is Google. Before that it was Microsoft. And before that it was HP. So these companies may set a bar for product managers that isn’t necessarily due to the job requirements, but more due to the cultural requirements, in order to gain the team’s respect, and work effectively with others in the company, including and especially the company executives.

So if your objective is to be a product manager at somewhere like Google, and you don’t have deep first-hand technology experience already, my suggestion is to get a job as a developer and spend a couple years immersing yourself in that world. It won’t necessarily make a big difference in your ability to define great products, but it can make a very big difference in your ability to get accepted into the culture and work effectively with the rest of the product team.

Email to a friend

Sign up for the free newsletter here.

One question I get quite frequently is “Google is making boatloads of money, so how can we do product management like Google?” Or another common variant is “Apple creates fantastic products. How can we do product management like Apple?”

You can understand why some might look at Google or Apple and think they should just clone what they do. But odds are they’d be making a big mistake.

Don’t get me wrong. While Apple and Google have very different models of product management, on the whole I’d argue they’re right for their companies (at least as long as their founders continue to stay so deeply involved in product).

But I have yet to recommend Google’s model of product management to other companies. And in the case of Apple, to implement their model you’d have to clone Steve Jobs.

The product management model for Google is very different, and I argue it needs to be, and the same is true for Apple.

While there are a set of skills that are important for all tech product managers – skills like assessing opportunities, defining product principles, product discovery, and prototype testing – there’s more to succeeding in an organization than just the skills involved.

It’s much like a sports team. Yes the skills are critically important. If you can’t catch a ball, you won't go far as a receiver. However, winning requires more than skills. It requires having a game plan or strategy for winning, working well as a member of a team, adapting to your opponent, the playing field, and the conditions.

Similarly, building a successful product management organization requires not only developing the skills of your product managers, but making sure they know how to work effectively with the rest of the product team, as a key part of your company’s overall product development organization and product development process, and knowing how to create the type of products your company requires, and knowing how to compete successfully in the markets you play in.

When I talk with a company about the “best” product management model for them, I’m looking at several factors, including:

- The Type of Product. It matters whether you’re producing a consumer internet service, a consumer electronics device, enterprise software, or a small business services. There are unique challenges of each and the model should suit the needs.

- The Product Development Process. For example, if the product development team is using Scrum there are very specific demands on the product managers and designers. Understanding the product development process is essential. Every process has limitations and the “best” product management model will proactively attack these limitations.

- The Role of Product Management. In many companies the roles and responsibilities are sliced up differently and the “best” product management model is one where the staff has the ability and the desire to serve the role that’s needed. This also applies to the other key related roles such as interaction designers and engineers, founders and executives.

- The Size of the Organization. A 12-person venture-funded startup with a very involved product-oriented founder, has very different needs than a 4000-employee public company with a large base of existing customers.

- The Company Culture. Sometimes this is in fact the dominant factor. For example, if you have a company where one or two people effectively make all the product decisions that matter (and want to continue doing so), then you want a product management model that facilitates this, rather than fights it.

Apple, Google, Microsoft, eBay, and Yahoo all have different product management models, and I argue they should. Could each be improved? Certainly. Could you learn things from each of them? Absolutely. But you won’t improve by trying to force-fit a model from one company into another.

Unless a company has made the decision that they want to try to change their culture, I instead typically focus on getting the company to embrace the strengths of their culture or process, and make sure the product management model they select is proactive in addressing the weaknesses.

Email to a friend

Sign up for the free newsletter here.

Article by Martina Lauchengco and Marty Cagan

We realize that most of our topics concern the development of Internet services, and mostly consumer internet services at that. But many product managers out there are working hard on other types of software products, such as enterprise or infrastructure software, both shipped software and hosted services.

One product area that seems to be a long-standing source of confusion for those in these spaces has to do with what are referred to as solutions products and the associated solutions marketing. Just as many companies stretch the truth to call their products a “platform,” many other companies like to claim their product is a “solution” even when it’s not.

The concepts of platform and solutions are both important and powerful, and those products that aren’t really up to the standard just dilute the meaning for the rest and confuse the market.

Before defining a solutions product, let’s first be clear on what constitutes a product in general. This may sound basic, but much software is not actually a “product” at all.

Here is how we characterize a product:

- people will pay for it; it delivers real and distinct value (and typically has it’s own SKU). Note that sometimes people pay by tolerating advertising, or by paying for support and not license fees, but one way or the other they’re compensating the provider.

- it works well in multiple customer installations. The point here is that it’s not a special; this is not custom software.

- your field and/or channel can effectively sell it. You provide the necessary sales tools and sales training.

- your company will stand behind it, providing support and adding improvements as necessary.

- your customers and/or channel and/or services partners know how to install, configure and customize the product.

You might argue that what we’re defining here is not just a product, but a certain quality of product. And we think that’s true. We consider software, even software produced by a product organization, to be just a wanna-be-product if it’s not yet being successfully used by multiple customers. In a sense, the software has to prove its right to be considered a product. Much like a platform that does not have any applications running on it isn’t really much of a platform.

Now, here’s how we describe a solutions product:

A solutions product has all of the characteristics of a “product” above plus:

- the software solves a business-level problem, often for specific industry verticals.

- the product may be based on an integration of one or more component-level products, which may come from your company or from partners, and they are pre-integrated.

- if appropriate, the product is certified with partner’s products as necessary (the customer needs to know the supported configurations).

We like solutions products because they speak directly to a business-level problem or need. In general, customers care much less about the underlying technology you use (other than early adopters), and more about whether you really solve their business problem. Your business problem might be disaster recovery, customer relationship management, or Sarbanes-Oxley compliance. But it isn’t what flavor of the operating system is used, or what type of router you select.

Note that there are some solutions products that are turn-key, and others that require professional services, and solutions products can be for any size customer from a single consumer to the largest enterprise, and also the software may be shipped (installed) software, or software as a service.

But it’s also important to point out what a solutions product is not:

- a set of instructions for how to use an existing product in a new way (customer’s won’t pay for that)

- a set of customizations/scripts from the field or other external source (not supportable)

There are many field or marketing organizations out there where they clearly see the customer demand for true solutions, but their product organization only provides the underlying component products, and they are often tempted to get creative and try to cobble together something that they hope they will have better luck selling. But while this might buy you a little time, as soon as a competitor comes along with a true solutions product the customer can easily tell the difference.

Related but the not the same as solutions products is solutions marketing. We also like solutions marketing over other forms of product marketing because solutions marketing:

- speaks to the business-level problem, aligning products with business value

- speaks to vertical industry segments, aligning value with a particular industry’s more specific and sometimes regulated needs.

- showcases live customer success stories in action, in order to prove the business value

- shows how to leverage products, professional services and business process knowledge or best practices to achieve business results

To us the trend is very clear and has been underway for several years. Increasingly customers are demanding products that directly address business-level needs, and they’re less interested in reading and comparing a data sheet of technical specs. Good solutions products and solutions marketing speak directly to these business needs.

Email to a friend

Sign up for the free newsletter here.

By Marty Abbott

In my earlier article I used the sports management analogy to make the case for actively managing the skills, skill levels and composition of your team. In this note I’ll discuss the topic of how to manage those activities. For this, we’ll leave sports and use a gardening analogy.

Even a novice gardener would not expect to rake some soil, throw some seeds, pray for rain and wait for a beautiful garden. Your team is no different; you must undertake the same activities in managing your team as you would in creating a successful garden.

Seed

Selecting the right flowers for our garden means paying attention not only to how they look, but how they will interact with the other flowers in our garden; will they steal too many nutrients or will the soil properly support their needs?

Managers in hyper-growth companies spend a lot of time interviewing and selecting candidates but usually not very much time on a per candidate basis and even less time pondering where they’ve gone wrong in hiring in the past. Finding the right individual for your job means paying attention to your past failures in hiring and correcting them. We might interview for skills, but overlook critical items like cultural or team fit. Why have you had to remove people? Why have people decided to leave?

Candidate selection also means paying attention to the needs of the organization from a productivity and quality perspective. Do you really need another engineer or product manager, or do your pipeline inefficiencies indicate additional process definition needs, tools engineers or quality assurance personnel?

One final point here is that far too often we try to make hiring decisions after we’ve spent 30 minutes to an hour with a candidate. We encourage you to spend as much time as possible with the candidate and try to make a good hire the first time. Seek help in interviewing or add people whom you trust and whom have great interviewing skills to your interview team to increase your chances of a good hire the first time. Call previous managers and peers and be mindful to ask and prod for weaknesses of individuals in your background checks.

Feed

Feeding your garden means spending time growing your team. Of all the practices in tending to your team, this is the one that is most often overlooked for lack of time.

The intent of feeding is to help grow the members of your team who are producing to the expectations of your shareholders. Feeding consists of coaching, praising, correcting technique or approach, adjusting compensation and equity and anything else that creates a stronger and more productive employee.

Feeding your garden also means taking individuals who might not be performing well in one position and putting them into positions where they can perform well. However, if you find yourself moving an employee more than once it is likely that you are avoiding the appropriate action of weeding.

Also, feeding your garden means raising the bar on the team overall and helping them achieve greater levels of success. Great teams enjoy great but achievable challenges and it’s your job as a manager and executive to challenge them to be the best they can be.

Weed

While you should invest as much as possible in seeding and feeding, we all know that underperforming and nonperforming individuals choke team productivity just as surely as weeds steal vital nutrients from the producers within your garden. The nutrients that are being stolen in this case are the time that you spend attempting to coach underperforming individuals to an acceptable performance level and the time your team spends compensating for an underperforming individual’s poor results.

Weeding our gardens is often the most painful activity for most managers and executives and as a result it is often the one to which we tend last.

While you must