Resources > Articles

Confessions of a Nontechnical Product Manager

Post Author
  • Julie Babb is a product manager at Pivotal Labs, the agile development services unit of Pivotal. She works with clients to wrangle digital teams, obsess over process and create momentum. She also shares insights on making things for partners like Game Developers Conference, New York University?s Interactive Telecommunications Program and Tribeca Film Festival. She can be reached via Twitter @awkward_hug.

product team

My friend Matt was helping a client adopt a more Agile software product development process. His first question to me was: “How do we test a product manager applicant’s computer science chops?” To which I replied, “Who says your PM has to code?”

As a “nontechnical” product manager and entrepreneur who has overseen the development of many projects from mobile games to multiplatform marketing campaigns, I get variations on this question a lot. Some employers and clients fear that product professionals who don’t code won’t be able to communicate properly with their development team.

Of course, every project is different but the two roles require very different skill sets. Personally, my lack of formal computer science training has never held me back, and can often be an asset. Here’s six tips for current and aspiring product professionals who don’t code:

1. The Product Is the Boss

A good product professional is a leader, but is not a boss. The product is the boss. Now here comes the corny business-book truism: Your top priority at work is to make your boss look good. Your job in a product role is not to bark orders at designers and developers, nor is it to be subservient to them. Rather, you are there to communicate effectively with the entire team including executives, marketers and salespeople, to make sure the product is great. A truly great product professional keeps the team focused on that common goal and helps determine the best path to get there.

2. Tell a Story with Your Product

In user-focused design and development, we can think of each feature as a “story.” When we describe each development task, we are essentially writing a story that will lay out the scenarios and requirements that allow the developer to dive in and formulate a solution. It’s important to remember that although we must define success, we don’t need to know the exact path to get there. In fact, good story writing is not technical at all. It is a unique language that bridges user needs with desired outcome; developing this skill requires empathy, attention to detail and systematic thinking. Tell your team a great story and they will come back with the technical requirements and functions that bring it to life.

3. Be Available

Writing a good story is an important first step, but your job doesn’t end there. You are an integral member of the team, and you must be available to facilitate, translate and communicate. Need a better feature description? Rewrite it and make sure everybody is on board. Having a communication problem with a team member? Fix it ASAP. Don’t hide behind Gannt charts or shift the blame when challenges arise. Tackle things head on with your team, and listen to them.

4. Ask Questions

I’ve never worked with a developer who wasn’t able to easily diagram a stack for me or describe how an important subsystem works. Most of the time, developers are excited to share their knowledge. You just have to ask. This understanding is an advantage that product professionals with a computer science background bring to the table, but it’s a skill that a nontechnical PM can easily develop. The more of this knowledge you accumulate, the better you’ll be at predicting how long things will take—and this will help you and your management team prioritize. In the meantime, you have options. Bring a developer into planning meetings to contribute, or avoid committing to timelines without consulting the team.

If you walk away from a technical conversation a bit confused, jot down the bits you understood and the things you didn’t and research it on your own later. It’s probably not imperative that you understand a complex development system now, but a better understanding may help inform a conversation or decision in the future.

5. Speak Up!

You may not know the ins and outs of C++ or how to whip up a web app in a couple of hours using Ruby on Rails, but don’t underestimate the value of your own experience and common sense. Even the best developers need help sometimes. And a good product professional can be a trusted collaborator to bounce ideas off of.

When a developer asks me to help with a technical problem, I start by discussing the feature from the user’s perspective. Then I transition to the developer’s point of view. Is the basic logic sound or are there holes in it? Is there a more simple way to get the same results? Is it built on, pulling from or sending out to other parts of the application? You’d be surprised how valuable your new perspective can be. Sometimes just identifying the trade-offs with technical decisions can help your developer choose a direction to best move forward. Code isn’t the only language developers know. Every feature is a series of rules that follow a system of logic that can be discussed in plain old English—or in diagrams, visuals and even emoticons if your coder doesn’t speak English (which I’ve also experienced).

6. Listen

Just as you may be able to inspire a coding solution for your developer, every team member can inspire product solutions. Encourage the entire team to volunteer feature ideas, share cool new capabilities, voice insights from data that may have been missed and find easy wins.

Being a good listener and making sure everybody is comfortable sharing their ideas will ultimately be a huge benefit to the product. And you definitely don’t need technical training for this skill—which may be the most important one.

Author

  • Julie Babb is a product manager at Pivotal Labs, the agile development services unit of Pivotal. She works with clients to wrangle digital teams, obsess over process and create momentum. She also shares insights on making things for partners like Game Developers Conference, New York University?s Interactive Telecommunications Program and Tribeca Film Festival. She can be reached via Twitter @awkward_hug.

Author:

Other Resources in this Series

Most Recent

The image features the term use scenario being revealed underneath a ripped piece of paper
Article

What is a Use Scenario [ +7 Examples]

The purpose of drafting use scenarios is to help your development and design teams to start thinking about solutions. Context is the foundation of innovation, and you’ll be providing a tool that will be the starting point for collaborative and productive meetings.
Article

[Comprehensive Guide] Product Owner vs Product Manager

Learn how to separate the roles of product owner and product manager on Agile teams and uncover some common challenges with confusing these roles. Including a short primer on the Agile revolution.
Article

Use Scenarios are Stories That Provide Context

The problem with today’s user stories is that they aren’t interesting. And they aren’t stories. The solution is use scenarios. It’s a narrative. It explains the problem in the form of a real-life story.
Article

Benefits of Bundle Pricing

Bundle pricing is simply a strategy where services or products are packaged together for one (often reduced) price rather than priced separately. This article covers some benefits of bundle pricing followed by a system for getting started.
Article

A Quick Guide to Value-Based Pricing

Value-based pricing begins with knowing the customer’s willingness to pay based on the perceived value of your product. You can charge less than a customer’s willingness to pay, and they feel like they’ve received an

OTHER ArticleS

The image features the term use scenario being revealed underneath a ripped piece of paper
Article

What is a Use Scenario [ +7 Examples]

The purpose of drafting use scenarios is to help your development and design teams to start thinking about solutions. Context is the foundation of innovation, and you’ll be providing a tool that will be the starting point for collaborative and productive meetings.
Article

[Comprehensive Guide] Product Owner vs Product Manager

Learn how to separate the roles of product owner and product manager on Agile teams and uncover some common challenges with confusing these roles. Including a short primer on the Agile revolution.

Sign up to stay up to date on the latest industry best practices.

Sign up to received invites to upcoming webinars, updates on our recent podcast episodes and the latest on industry best practices.

Training on Your Schedule

Fill out the form today and our sales team will help you schedule your private Pragmatic training today.

Subscribe

Subscribe

Training on Your Schedule

Fill out the form today and our sales team will help you schedule your private Pragmatic training today.