Interview with a Director of Product Management

The 4th Interview in the series is with the Director of Product Management at NetStreams – Paul Young. Paul is also the author of the product management blog: “Product Beautiful” and has a proven track record in product leadership, thought leadership and problem solving.

1. What's your academic background/training?
I have a B.S. in Radio-Television-Film from the University of Texas at Austin.

2. What did you do before you where a product manager?
I was a web-based applications programmer (Oracle, PHP).

3. Where did you work before you worked for NetStreams?
Before NetStreams, I was a Product Manager and Product Marketing Manager for Cisco Systems.

4. What inspired you to become a product manager?
I was one of those annoying developers who always asked "why?" "Why are we doing this?" I found myself talking to the Product Managers quite often. I also noticed that the Product Managers were the people that got to work with the Executive team most frequently and had an influence. I knew that I wanted to make a similar impact, so I strove to join that group.

5. How did you make the move from being a developer to becoming a product manager?
I was a developer for a web-based portal that Cisco's service customers used to check service requests and trouble tickets. The product manager for that product went on maternity leave and when she came back, moved to a different product. Because I was intimate with the product's features, I moved into that role. Later Cisco gave me additional services to manage (managed WAN and LAN services).

6. What do you like best about your job?
I like talking to customers! What I really enjoy is talking with customers who bought into our products because they solved a problem they couldn't solve any other way. That's cool - and profitable.

7. What do you least like about your job?
Ankle biters. That is what I call the little tactical things that you have to do to keep the lights on. Quarterbacking products for trade shows, explaining how the trade off process works to your sales team for the 82nd time, and handling hyperventilating Executives who think the sky is falling because of some new competitor.

8. How do you keep up with the latest technologies?
I try to read a lot. I make heavy use of Google Reader to keep up with RSS feeds from favorite tech sites like Engadget. I also regularly read the other Product Management blogs that I link from my site, Product Beautiful. I am always amazed and humbled by the great thoughts and posts that other Product Management bloggers are creating.

9. Describe your PM job in one sentence.
Product Management is 50% strategy, 50% tactical, and 50% listening. Oh, that was supposed to be specific to my PM role...here goes... Directing the Product Management team at NetStreams is all about making sure that we fire the very limited development ammunition we have at the right targets in the market.

10. What's your dream product to manage?
I've mulled this over many times. In general, my dream product is something that is blazing a new trail, a product that is in a greenfield area where I can do real problem discovery and think about new problems being solved in ways that haven't been done before. I would really like to focus on a product that helps people in some way. Software as a Service (SaaS) seems like a wonderful model from a Product Management perspective, because of the ability to quickly adapt the product to new problems and experiment with low overhead. I'm always interested in how other Product Managers are reacting to agile.

11. How would you describe managing product development before you/your company adopted agile?
We haven't adopted agile, mostly because it is less applicable to mixed hardware/software products. The hardware gears turn more slowly than the software gears which can move very fast, but since we sell through a channel, our users can only accept software updates to their hardware so often. So agile would be counter-productive in our case.

12. What would be the top three attributes you need to do your job?
Curiosity , Patience and Good Listening Skills.

13. What do you do when you're not managing products (outside interests)?
I try to keep up my health, so I run and play basketball a couple of times per week. Sometimes my wife and I get down to 6th Street to see my friend Mike Hoffer play with one of his many bands, like Calling Jack Burton (a great 80's cover band if you're ever in Austin).

Paul gives some insightfall comments on how to get along with the engineering/development team - and how to make the transition to from where you current are to being a product manager. Refer to the article"How to become a product manager and How to along with developers" for details.

How to get along with the development team

Paul Young shares his thoughts on how Product Managers can get along with the development team.

You need what I call street cred. That means a couple of things:

first, you have to speak the language of development. Developers love to needle anyone they perceive as "marketing" (note: as a marketer you are automatically one-step above a dung beetle in the eyes of most programmers) and often times, they try to bully you! I've had programmers tell me my ideas were stupid, that they were never going to do that, that that feature would get into the product over their dead body, etc. Can you tell I've done a lot of turnarounds on Development-driven companies? You have to be able to stand tall against that pushback, and the Number 1 weapon in your arsenal is customer feedback - specifically statistically valid customer feedback.

Be able to show that you talked to a significant and representative portion of the market and most arguments will crumble before you. Second, you can't tread on their turf. It helps if you've been a developer in the past because you know what their turf is; but I'll try to explain it.

You own the "what." The developer owns the "how." You're not allowed to roll your eyes when they start going on about XML and relational databases and flash key frames and Ruby-on-Rails. Your only acceptable answer is "Wow, it sounds like you've thought about how to conquer this problem a lot. I don't get into the implementation of how to solve this problem, but it I'm sure that you and the team can apply some really cutting edge technologies against it!" As part of the same token, you can't go down the next day and complain that they chose a Java implementation when you really like .NET - you have to trust the team to choose the best tool for the job and the skill sets of the people doing the implementation.

I have seen lots of ex-programmer wannabe Product Managers fall down here, don't EVER get into a heated debate on the technology choice with the developers - you'll lose (and you should!).

How to become a Product Manager

Continuation of the interview with Paul Young
What advice would you give some one who wants to move into product management?
Product Management is unique in that there isn't a well defined career path for a product manager, unlike operations or marketing. I don't know a lot of people who have intentionally sought out Product Management as a career, most people I know have "fallen into it." My best advice is to find a smaller company that is thinking about starting a Product Management group - it may be easier to break into than a large company. I also feel that being well rounded and having good business fundamentals are key.

If you're a developer, find some way to demonstrate your business savvy - you could even do this in your current job. Surprisingly few developers are "in tune" enough to understand the business and provide good trade offs; I'm dying for programmers who can tell me "I understand you want X, but how does Y work for you, it gets you feature a, b, c (but not d), at half the cost and time, and sets us up architecturally for the future." Instead of: "That feature will take 24 months."

If you're currently in a marketing or operations position, demonstrate that you can "speak geek." Since Product Managers are required to regularly interact with and negotiate with development, you need to be able to show that you have the street cred with the developers and that they're not rolling their eyes as you walk out and muttering "marketing idiot."

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.

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.