Browsing Tag


How Technical Should a Product Manager Be?

Recently, the CrankyPM was in top form with her post about the 6 Types of Software Engineers. That kicked up an interesting response from a developer, who attempted to classify the 4 Types of Product Managers. The response post re-raised the age old Product Management qualification question: “How Technical Should a Product Manager Be?”

There are two big philosophical battles for Product Manager qualifications: level of technical competence, and level of domain expertise. Arguments for more technical include:

  • Less likely to be B.S.’d by development
  • More easily builds rapport with development
  • Understands what is possible

Arguments for less technical include:

  • Won’t be tempted to get “in the weeds.
  • More outside-in than inside-out focused
  • Doesn’t filter requests to development based on own biases of what is possible

I actually started my career as a developer. To the point of the article linked above, I wasn’t a “guru,” but I sought to get out of development because I didn’t want to always be implementing someone else’s vision. I am thankful for that experience today because I do feel like it enables me to speak with developers more on their terms and relate to the challenges that they face. I’m not just a PHB saying “here’s the date – make it happen!” It helps, and as a PM having a good relationship with your team is important. However, it also leads to one of the biggest myths of Product Management…

“Being Technical Enables me to Know When Development is the Schedule.” It doesn’t matter how good your relationship with development is, you don’t know if they are padding the schedule (or rather, how much). Most development teams have no idea of how long a feature will take to build. Even if they did know exactly, unless you are in the code and are familiar with everyone’s workload and skills you’re not going to know.

There are at least two ways around this problem: Evidence based scheduling, which looks at past performance against projected schedules as an indicator of how much to trust a developer’s estimate, and Agile, where you can lock in dates and flex scope instead (which just shifts your problem from dates to scope).

The other knock against being too technical is that you will filter requirements into development based on your own biases of what is possible. A Product Manager should not know or care about how a solution is implemented, only the time and cost to fulfill the requirement. If the requirement is “The lawn shall be cut to 2.5 inches above ground level every 2 weeks” do we care if the solution is a lawn mower vs. a billy goat vs. 75 developers with scissors? No!

It is the job of development to tell us how much something costs, and our job to go into the equation assuming anything is possible. “Man on Mars?” Sure – 100 Trillion dollars and 35 years! “100 MPG car?” 15 Billion dollars and 7 years. “Invisibility cloak?” OK, some things aren’t currently possible (yet). But put in the requirement, because developers get off on a challenge!

Another way to get accurate info from Development is trust. If you have a good relationship with the Alpha Dog developer, they will tell you how confident they are in an estimate or how much they are padding. But beware – I’ve seen junior PM’s turn around a give this info to management thinking that it will get them recognition. Worst. Decision. Ever. The VP hears that the schedule is padded 3 weeks, trims the timeline by the same, and your bridge with Development gets burned down. Poke and prod for details, but keep it “in the family.”

A final note on the “technical” product manager: every minute you spend talking to a developer is a minute you are not spending listening to a customer or potential.

How technical do you think a PM needs to be?

The Failures and Successes of Open Source Product Management

AntI kicked over a small ant hill last week with my post about the (lack of) Product Management being a fatal flaw to open source software. Both CNet and Linux Today chimed in, and that story incited some really good comments. Some of the commentators were gracious enough to continue their dialogs with me in more depth over email. It’s only fair that I follow on that post with some of the great points they made.

First, there was some confusion between Product Management and Project Management. Product Management is still poorly understood and inconsistently implemented in technology companies, so it’s understandable that lots of open source programmers may never have worked with a good Product Manager. Here’s an email exchange I had with a commentator (who asked to remain anonymous):

Paul: …maybe we’re talking past each other on the definition of project management vs. product management…

Anonymous: …I use them nearly interchangeably since all products result from projects. The problem I have in your posting is your blanket implication that development style makes FOSS management inferior….

…I disagree strongly that project and product mgmt are interchangeable terms. Product management is the discipline of discovering, documenting, and prioritizing user problems, it looks at the market strategically and seeks to understand where the greatest user pain is and (in commercial companies) which problems can be solved with the most profit. Project management is tactical scheduling, resource allocation, etc…

This leads to Point #1: The “Product Management Probem” is not unique or limited to open source projects. This is completely valid. You can easily point at Microsoft or other commercial software companies for examples of products that had poor product management and don’t necessarily solve a pressing need. The Pidgin example happens to offer a teaching opportunity in the FOSS world, showing that no person or model is perfect.

Point #2: Many commenter’s stated (paraphrased): “We don’t need Product Management, that’s for commercial companies; free software already has a method to determine wants and needs across groups of users – it’s called forking!”

Forking is when a developer decides to branch off of a project to create something different, usually withing the same vein and built on top of the work that has occurred to-date. In fact, there is already a fork of Pidgin called Funpidgin that exists just to give users back the features that the Pidgin team “took away.” I would say that forking is a very inefficient way to solve this problem, but a commenter smartly called me out on that point saying that unlike in commercial companies, open source projects are not resource-bound – they can afford to be inefficient.

The main point of the post, beyond even the Product Management topics, is that a FOSS project can have one of two primary goals: either the developers are creating for themselves, or they are creating for others. To create for yourself means that you recognize user input but don’t feel any obligation to take it since you’re building an application for yourself. If the user happens to enjoy it, great. If not – fork and make something you like.

If you’re creating for others, you should be interested in the wants and needs of your target user base. This might mean forgoing a “cool” or technically challenging feature like auto-resizing text boxes. Now that open source software looks, feels, and acts like many commercial packages, users assume that the application was developed with their needs in mind. If the application does not meet their needs, they feel justified in offering feedback. This is where the disconnect comes from: users who assume that an application was developed for them and programmers who believe they are building primarily for themselves. If the programmers are interested in working for a larger user base, a strong product manager could help them fill that gap.

What if when you went to to SourceForge, you saw a badge affixed to the link that told you if this was a for-developers or for-users download?

Who are we creating for?

At least if you understood this bit of information at download time, as a user you wouldn’t bother going to offer feedback to a team that isn’t interested.

Point #3: “FOSS projects air their dirty laundry for the World to see, whereas commercial products get to keep it inside their four walls.”

Yes and no. Yes, open source is out there for everyone to see. Don’t think for a second that just because a product is commercial that the tradeoff decisions those teams make don’t spill onto the Internet. Just look at Microsoft Vista for an example. Or Facebook’s advertising platform.

Point #4: “There is Product Management in open source today! See JBoss, Mozilla, and others!”

This is an important point that I’d like to recognize. There are companies and projects that are contributing PM to FOSS projects.

I’d like to thank everyone who participated in the discussion!