Month: November 2007
Ran across this posting on the Infoworld site. Some interesting tidbits here. And if you think working as a PM in a commercial ISV is tough, it’s much more complex in an Open Source environment where developers clearly have a lot of pull. But, some things are the same all over. For example, the Engineering view of what Product Managers do:
When I joined MySQL four years ago, there was quite a lot of debate about product management. We didn’t actually have any product managers and the view in Engineering was “we don’t need ’em.” The rationale was that we were so far behind in implementing features requested by customers that there was no need to have another opinion. “We already know exactly what we need to do” or “The Community tells us what we should focus on” were typical responses.
So the engineering view is that Product Managers are only focused on feature prioritization. I worked for a company that had that view. I said to the head of the PM group, that I didn’t join the company to be “requirements boy”. i.e. it’s not just about collecting and prioritizing requirements.
The post goes on to describe how the engineers were convinced that they needed to have Product Managers.
By focusing on the skills of the candidates rather than the grey areas of the role, it became a much more productive discussion. Everyone saw that they brought a real world perspective that would be valuable. And we were successful in recruiting the candidates. A few months later, the question became “Where do we get more guys like this.”
I think this is a good strategy if you work in an environment that doesn’t understand the need for and value of Product Management. Identify the gap in the company and show how the PM team can fill it. It may not always work, but in my experience, there is rarely an overabundance of real-world experience of the target audience inside a software company.
I came across a new blog, a la 360, which just started a couple of months ago. The author recently posted a couple of articles related to Facebook. One blog asks “Which problem is Facebook solving?“. Another discusses market segmentation WRT Facebook.
I like both articles as they ask straight forward and fundamental questions that we all should be asking ourselves (if we aren’t already) when looking to create a new product or service. Now one could argue that without clearly identifying a target set of problems or clearly segmenting the market, Facebook is more successful than 99% of internet applications, so why bother?
The issue is not about Facebook, but simply about reminding ourselves to do our homework to help improve the chances of success of our products. For every Facebook that succeeds, there are hundreds that fail.
In part 1 of this series, I talked about the lack of maturity in the product management role in technology companies. Computer technology and software themselves are rather immature, and given the rate of change in the computer technology industry, that immaturity will be here for some time.
Maturity takes time
It took over 80 years — from the introduction of Ford’s Model T in 1908 — for the automobile market to reach a level of what I would call maturity. And by maturity I mean the ability for manufacturers to consistently produce high-quality cars and trucks that consistently deliver value and address market needs. OK, not all car companies do this, but companies like Honda and Toyota certainly do and they have proven that it is possible to not only systematically do this, but to do it even in the face of severe economic and political obstacles.
I recently got rid of my 12 year old Honda Civic. We bought it back in 1995 just after we had our first baby. Later, when we bought a minivan (Honda Odyssey), the Civic became my daily commuter car.
I drove that car every day to work and back for about 10 of the 12 years: on average about 70 km per day. I would have kept driving it, except that a few weeks ago, someone drove into the side of my car as I was driving home. It was dark, and raining, and there was heavy traffic on the road. Luckily no one was seriously injured. After over 220,000 km, I had to turn in the keys on the Civic.
Recently I picked up my replacement car. It’s a great little car and driving it to work is easy. And guess what, it’s a 2003 Honda Civic. Yes, I went out and bought a newer version of the same car. And why wouldn’t I?
My previous Civic worked, plain and simple. It didn’t require special maintenance of any kind. I’m not a great car owner to be honest. I’m not always timely with my oil changes. I don’t check the tire pressure as often as I should. But my first Civic kept on working over the 12 years and had someone not run into me, I wouldn’t have gotten rid of it.
And coincidentally last month, Consumer Reports named several Honda and Toyota models as “Good Bets” for vehicles to last for 200,000 miles (320,000 km). Funny how no American makers made the list.
And why would they? The Japanese auto makers have transformed the automobile industry in the last 35 years. From a humble start selling low priced, low quality cars, both Honda and Toyota have embraced continuous improvement in all aspects of their design and manufacturing process. Numerous books have been written about these companies particularly Toyota:
So what does this have to do with software product management? Everything.
Product management must keep the process of continuous improvement in mind at all times. This not only means continuous improvement in the products delivered to the market, but continuous improvement in the processes, both internal and external, that deliver those products to market.
This is where the function of Product Management must be considered as opposed to the role of Product Manager.
Many companies mistake the two as being the same and that is a source of problems. Consider the analogy of the function of Engineering and the role of a software engineer. The former includes the latter, but there are other roles in engineering, such as architect, development lead, interaction designer, tester etc. that help compose the role of Engineering in the company. Each of these roles plays a well defined part in ensuring the output of Engineering meets demands and expectations. The same is true for the function of Product Management.
Software Product Management must focus on optimizing the business side of software, ensuring that the R&D investments made in developing product are the best ones given available information and that the processes used to roll out and take products to market are working to maximize the return on those investments.
Granted, this is not how all software companies view Product Management, but to be honest, they should. Because in reality, if Product Managers aren’t doing this then who is? Finance? Marketing? Sales? Sr. Management? Sr. Management is responsible for the overall business, and in small, single product companies, that may overlap completely with the business role of the PM. But in any company that has multiple products, Product Management must be focused on optimizing the business of the products and product lines they manage.
Now I’m not saying that Product Management should ignore the technology. No, that is a key aspect that needs to be addressed, but one shouldn’t assume that the same Product Manager, who is looking out for the overall strategy and business objectives of the product or product line can also focus on the technical details of the product as well.
In the part 3, I’ll delve into how to decompose roles in the Product Management function to maximize the output of the team.
The rest of the series
Product Manager vs. Product Management (part 1)
Product Manager vs. Product Management (part 2)
Product Manager vs. Product Management (part 3)
Product Manager vs. Product Management (part 4)
Product Manager vs. Product Management (part 5)
Product Manager vs. Product Management (part 6)
Product managers are always looking for better ways to get feedback from customers on which new features are most important. A few companies have embraced the “Web 2.0” model and are putting their feature candidate lists out there for everyone to see and comment on.
Dell has Dell IdeaStorm where anyone can register and submit their ideas and vote other ideas up or down.
Salesforce has, not surprisingly, creates a SaaS service which they sell to other companies but which they also use themselves. IdeaExchange is viewable by everyone, but only registered Salesforce users can comment or vote on ideas.
Sun has always made their bug (and FR) database for Java publicly available, which was certainly great back in my days as a Java developer.
It’s an interesting idea to implement this for the product I’m currently working on, but is it always appropriate? Just like with roadmaps, it’s not a good idea for small companies to put too much data out in public as it gives too much away to competitors. For companies like Salesforce.com, Sun and Dell, there’s not much here that’s really a secret; it wouldn’t take a competitor very long to figure out the gaps in specific functional areas of Salesforce. But consider your own product – would giving away these details to competitors be a bigger drawback then the greater level of customer engagement you’d get in return?