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.