From Software Engineer to Product Manager to Founder of SVPG - Interview with Marty Cagan

Marty Cagan has worked for several leading Hi Tech companies such as Hewlett-Packard, Netscape Communications, America Online, and eBay. During his career he has performed most of the roles that are key to any technology company: product management, software development, product marketing, user interface design, usability engineering, technical writing, software testing, engineering management, and general management. Marty is a founder of the Silicon Valley Product Group a company that provides services that span the full product life cycle. He also authors a news letter that both informs and inspires. In this interview Marty shares his thoughts on Product Management.

1. What’s your academic background/training?
My education is in Computer Science, and I also did the Stanford Executive Business program. But my real education came from having the opportunity to work for and with from some of the best product minds in our industry.

2. What did you do before you where a product manager?
I was a software engineer at HP Labs.

3. Where did you work before you set up Silicon Valley Product Group?
I was previously SVP Product Management and Design for eBay.

4. What inspired you to become a product manager?
I learned the hard way that it doesn’t matter how great your engineering team is if the product manager doesn’t give them something useful to build.

5. How did you make the move from being a developer to becoming a Product Manager.
I found someone that I thought did this job really well, and he pointed me in the right direction.
6. What do you like best about the Product Management job?
Creating products and services that are used and loved by millions of users and customers.

7. What do you least like about the Product Management job?
So many people out there have no idea what product management really is. They think it’s marketing. Little wonder the vast majority of products and services are such dismal failures.

8. How do you keep up with the latest technologies?
If you love technology like I do you can’t help but want to follow developments closely. Also, many of my friends and colleagues are leading engineers and architects and I constantly learn from them.

9. Describe the Product Managers job in one sentence.
This is the person responsible for discovering and defining a product that is useful, usable and feasible.

10. What’s your dream product to manage?
Been there and done that (and extremely grateful for it). Now I love to help others create their dream products.

13. What would be the top three attributes you need to do the Product Management job?

#1. Willingness and ability to engage deeply with engineers on technology – to understand what’s just now possible.

#2. Willingness and empathy to engage deeply and directly with end users and customers to understand their needs. Especially to try out your ideas on them and not let your ego get in the way of learning, adjusting and identifying the right product.

#3. Willingness to do whatever it takes to get that product shipped.

14. Product Managers come from different backgrounds: what advice would you give someone who wanted to break into Product Management who had an engineering background. How would that advice differ if they did not have a strong technical background?
(That’s a great question and one that I want to think more about and then probably write an article on for my newsletter, as many software developers talk to me about switching to product management. For the second part of that question, for people that aren’t technical, I happened to write about that in my last newsletter: http://www.svpg.com/blog/files/are-you-tech-enough.html)


15. Looking back, as a former Product Manager, what’s the one product (or product range) that has brought you the most satisfaction?
My favorite job ever was at Netscape as the Internet was just emerging. New technologies were being invented almost constantly, combined with daily interactions with developers and customers from startups and established companies all racing to learn how they could use the Internet to help solve long-standing problems. A great time to be a product manager.

Part #10 Justifying Time to Research with Agile

Agile Research

I worked for a company that designed and manufactured niche signal processing equipment for the broadcast industry. Part of the secret to the company’s success was that it was not shy in investing significant amounts of revenue in a research department as well as allowing its engineers to carry out their own research projects.


In my opinion all technology companies need invest in research, but think about adopting some agile principles in funding research to ensure that time can be traced and that the business gets a good return on investment (ROI) for research that has been untaken. Here's my list of five potential things that you can adopt when thinking about trying to find time during your busy day to justify time to carry out research.
#1. Identify areas that require research and build it into the sprints backlog.
#2. Ensure that product managers have time to research so that they are up-to-date on the latest widgets, gadgets and technologies. Product management research will not be part of the backlog but nonetheless the research needs to be done in a time-boxed way. It may be an idea to set your self a research goal for each sprint (using the start and finish of the sprint as time markers).
#3. Give time for the engineering team and product managers to formally report back on what they have researched.
#4. Take note of any newly introduced functionality or enhancements that comes about as a result of the research that has been carried out.
#5. Track the benefits (in terms of increased traffic to your website - equipment sold because of the additional feature etc…) and therefore prove business benefit and therefore ROI.

For more on this topic read: Innovating in Large Companies which encourages us to spend 20% of our time in research and innovation.

Part #4 Agile Customer Support

I worked for a company where in the morning I was booked on a flight to troubleshot issues at a customers site in Switzerland at Midday it had changed to Germany and by the time I went home I was booked on a flight (for the next day) to Florida. That’s agile customer care for you. The ethos of the company was to adapt your schedules to meet the customers' need. Indeed the competitive edge that we had was the fact the we responded to the customers needs and had a well trained customer support department which was backed up by a test dept, R&D, project managers, product managers, technical sales and even the technical manager and technical director who all had the ability to visit customer sites with the view of fixing problems. The agility of all technical staff meant that the company had a great reputation for customer service and therefore won repeat business and experienced greater ROI year on year, that's got to make good business sense!

I believe that our success was down to two very simple attributes that each member of staff had adopted:
1. We worked hard to be better than the competition.
2. Everybody was customer focussed.
This meant there was very little time for internal company politics and the petty little immature things that causes a company to loose its way.

Success depends on how agile your customer support is – is it down to a few individuals with the job title of 'customer support engineer' or is it the whole company.

See also: Part#1 Implementing an Agile Frame Work

Product Management and Knowledge Sharing

Sources of knowledge for Product Managers: knowledge within people.

If HP knew what HP knows, we would be three times as profitable stated CEO Lew Platt.

Companies where knowledge exists in discreet islands (business units or departments) seldom benefit from the synergy of everyone knowing what everyone else is up to and even more important sharing of experiences with one another.

I worked for a company several years ago that had half a dozen R&D labs located around the south of England. Each lab was pretty much a business unit in its own right. Product Managers were located with the R&D teams. This meant they we were close to where the products were being designed and had the opportunity to monitor progress and get close to the technology. The company then took the decision to move all Product Mangers to a central location – this was aimed to help us all share cross product knowledge. Then it moved us back with the R&D teams and finally, just before I left it centralised us again. The point is where Product Managers should sit as to best facilitate knowledge sharing.

My current company, up until recently, had all the Product Managers sitting at one end of the office and the development teams sitting in their product groups occupying the rest of the office. A few months ago we had a total reshuffle, principally due to the fast pace of growth resulting in the number of people joining the technology department.

Now the Product Manager teams sit among their development and test teams. This has improved knowledge sharing and has promise of improving productivity. It will also aid in the new agile scrum methodology that we are adopting.

The implementation of scrum (an agile development method) also promises to improve knowledge sharing as product owners meet for sprint planning and sprint review meetings. The daily 10 to 15 minutes sprint meetings also means that fresh snippets of market knowledge will be periodically and informally fed directly to the development teams. This can only aid in ‘the team’ gaining a better understanding of the markets.

Knowledge sharing is important for the profitability, success and ongoing growth of products.

I will report more on scrum and the knowledge sharing benefits as time goes on.

• Do you have any experience in scrum fostering knowledge sharing that has resulted in improved products or features?


• Where do Product Managers sit in your organisation – among the developers or some where else?

Please feel free to post a comment or two.

See: sharing knowledge for more information regarding the benefits or knowledge management and product management.