Product Managers and Data Scientists

Over the past couple of decades, product management has emerged as an important function within any organization that is building technology products. Data science has arrived more recently but is also proving its value in helping to solve problems for customers. In data-centric organizations, there is an important symbiotic relationship between the two functions, but it’s not always clear where data science should fit in the product development cycle. Should data scientists be treated like developers? Analysts? Or something entirely new?

While both groups want to solve problems for customers, it is important to understand the differences in their fundamental mindsets. Data science is about exploring data, understanding its predictive possibilities and creating tools that use data to optimize defined performance metrics. Product management is about deciding if the things that are technically possible are actually worth doing from a business standpoint and if so, how those new capabilities should be delivered to customers as products or features.

Collaboration between the two groups is vital, but works best when each team has a clearly defined role and set of duties. Here are some approaches on how to successfully integrate data science into the product development process:

Data Science is the R in R&D – Data scientists need the latitude to explore problems that they think are interesting and come up with innovative approaches. Celebrate this. Not everything they do will address the problems you are currently trying to solve, but it is important to allow them the freedom to explore possibilities. Often, they will surprise you with a solution to another problem that will help shape your business in a positive way.

Data Scientists Build Great Prototypes – Projects work best when the data science team develops working prototypes using whatever tools they want. These prototypes demonstrate the requirements of a new system to software developers and others. Only once there is a working prototype that has been green lit by all the necessary parties should you move forward with building out the new capability in your production systems.

Lean Data Science is Possible – Once data science has developed a working prototype, the team should figure out the smallest increment that can be put into production to test it in the real world; a Minimally Viable Algorithm. This could be as simple as developing a workable process that provides alerts when certain conditions occur. This approach helps identify errors in assumptions and bugs in implementation before a full release that builds on the ultimate algorithm.

Data Scientists Do Great QA – I’m not referring to regression testing of code. If you are building a data product or an ETL process, a qualified expert needs to validate the data at some point. Data scientists are obviously the best candidates to conduct that oversight, so make their signoff part of the formal criteria for prototype acceptance. And after the development teams have built production versions of the prototype, don’t let the data scientists wander off to get buried in the next great paper-worthy research project. Get them involved in validating that the production features are indeed working as intended.

While a lot has been written about product management, software development and how product development processes should be designed, processes that incorporate the data science function are less well understood. Data science is often essential to the development of products that can compete in a data-intensive market. Developers and product managers are best served by finding ways to integrate data science into their projects from start to finish; from design to QA and through to market feedback. Data science is now an integral part of almost every technology ecosystem, and product managers everywhere should embrace their full involvement.

As published by iMedia Connection on 4/4/2014.

PRODUCT Manager v. PROJECT Manager

I was recently asked to highlight the key differences between Product Management and Project management. While the two functions are clearly seen as different by the practitioners, the lines of responsibility can get blurred for other groups.

In reading what others had to say about the issue, I came across a post by Jeff Lash that almost perfectly captures my view on the issue:

Project managers are responsible for the successful delivery of a project — a one-time endeavor with a goal, scope, deadline, budget, and other constraints. A project manager will work to align resources, manage issues and risks, and basically coordinate all of the various elements necessary to complete the project. As they relate to products, projects can be undertaken to build a product, to add new features to a product, or create new versions or extensions of a product. When the project is complete, the project manager will usually move move to a new project, which may be related to a different product.

Product managers are responsible for the overall and ongoing success of a product. Once the project to build the product is complete and the project manager has moved on, the product manager remains to manage the product through the entire lifecycle. Other projects related to the product may be initiated, with the product manager being the one constant stream throughout, defining the project goals and guiding the team to accomplish the business objectives that have been defined.

I only thing I would change here is to amplify the responsibility of the Product Manager as the voice of the customer in the development process. In owing the product lifecycle, the Product Manager must make sure the projects that are prioritized are the ones that best solve the customer’s biggest problems. This is the most important part of the Product Manager’s job.

Product Management and Start Up Maturity Cycle

A few weeks back, I had the opportunity to attend Practical Product Management training from Pragmatic Marketing.  The instructor, John Gatrell, said something about the maturity cycle in early stage organizations as it relates to product management that I had not considered before.

Jon said that in the beginning most startups are engineering led (this part I knew).  Since the founder usually leads the product development team, this is likely the one time when a company is most market-driven; where they are most focused on building the products to solve real market problems.  As the organization grows and functional specialization begins, a professional sales team is hired and the development organization become more removed from the market and loses some of this focus.

With the new sales team in place, the company focuses on top-line growth and the organization tends to become more sales driven.  One down side of a sales driven organization is that the sales team can get overly aggressive and will sell features that the product doesn’t necessarily support yet.  More and more the product roadmap gets determined by the commitments sales people are making to clients in order to close deals.  This approach helps win business but is not a strategic or thoughtful approach on how to evolve a product for long term market success.

Eventually, the sales team asks for help telling the company’s story and the organization will strengthen its marketing capability.  The marketing team will naturally focus on outbound activities like PR, collateral, and lead generation that help build the sales funnel.  At this point the company is talking to the market but probably not listening as effectively as it could be.

When the company reaches this point, it needs to evolve back towards a market-driven, listening organization that is centered around solving real market problems.  The Pragmatic approach emphasizes, and I agree, that the key role of the Product Manager is force this market-centric discipline on the development organization.  The Product Manager needs to synthesize all the information he or she receives to make data-driven decisions about how to evolve the product and not simply respond to the latest “must-have” feature from a sales rep.

As a side note, I’m glad that Pragmatic has certified me after 7+ years of operating without a license to practice product management.  It is quite a relief to be legit.

Product Management Reading

For the past several years, I’ve made a habit of clipping interesting articles about Product Management.  A friend recently asked for reading suggestions, so I thought I’d share my favorites here.

Be a Great Product Leader (Adam Nash) – This recent favorite concisely breaks down the role of a Product Manager into three key responsibilities; product strategy, prioritization, and execution.  It’s hard to argue with these three.  On prioritization: “At any company with great talent, there will be a surplus of good ideas…As a result, brutal prioritization is a fact of life.”  On execution: “In the end, product managers ship, and that means that product managers cover whatever gaps in the process that need to be covered.”

What Makes Someone a Great Product Manager at Google? (Quora answer by Edward Ho) – This response by an engineer at Google had two recommendations that jumped out at me.  First, “be an engineer.  I don’t mean that you actually need to be coding the product.  I mean you should be curious about how the product is built  as if you were an engineer.” If you’re not curious in how the thing you manage works, you’re not doing it right.

Second, Edward calls on Product Managers to be “[f]earless…the best PMs will speak to founders the same way they speak to engineers.”  Product Managers need to have the ability to “influence without authority” (to quote an old business school professor).  They are often lower in the organizational chart than the people who are looking to them to make important calls.  A good product manager can’t be intimated by this.

Why it doesn’t matter where Product Management lives in the Organization (The Cranky Product Manager) – I firmly agree with Cranky’s thesis on this.  I’ve worked for three separate product organizations.  The first two reported up through marketing and the current one reports up through engineering.  When product management is done correctly, it straddles both the business and technical teams so which ever one it formally reports to doesn’t matter.

“The assumption is that if we sit in Engineering we’ll be too spineless and too tunnel-visioned to focus on the customer, market problems, issues for the field, the competition, or market positioning.  But if we sit in Marketing that we’ll be so focused on empty soundbites and website color schemes that we won’t be able to give Development detailed enough requirements, that we’ll conjure up product features that can’t possibly be built (a la Warp Drive), and that we’ll stare vacantly into space instead of considering technical extension points (i.e. APIs) for our products.”

Frankly, anything by the CrankyPM is pretty good reading.

You Can Build it, but Can You Sell and Support It? (Saeed Khan) – Saeed has a great answer for the question “should sales and execution capabilities be taken into account for a product’s strategy.”  This needs to be a resounding “Yes.”  If you are developing a high price, high margin, complex product that requires high touch after sales support, you better have the capability to deliver that support.  The product strategy needs to fit within the companies core capabilities.

How Do Awful Products Get Shipped (Quora answer by Michael Wolfe) – We’ve all seen products that have been released before they were ready and wondered “how did that happen?”  Michael lists some of the organizational pressures and dynamics that can cause this to happen including: “If you don’t ship, the project will get cancelled and you’ll lose your funding anyway.”

Spare Me from Product Guys (HackerNews Discussion) – Aaron Harris posted on Techcrunch about the problem of “Product Guys” without real experience and the HackerNews community responded.  There is a lot of skepticism from this engineering oriented group on the value of Product Managers (including this).

Good Product Manager, Bad Product Manager (by Brad Horowitz) – This is a good overview for when Product Management is responsible for both the inbound and the outbound aspects of product management.  (It is also a great history piece on what it must have been like at Netscape during the browser wars.)  “Good product managers anticipate the serious product flaws and build real solutions.  Bad product managers put out fires all day.”  “Good product managers define good products that can be executed with a strong effort.  Bad product managers define good products that can’t be executed or let engineering build whatever they want.”

The Product Owner on One Page (Roman Pichler) – This is a nice, simple drawing of a Product Owners key responsibilities in an agile environment.

Seven Traits of Successful Product Managers (Michael Shrivathsan) – This was one of the first articles I read when I made the transition from business development to product management.  Hard to argue with any of this.

Parenting and Product Management

Cranky PM has a great post on Product Management and parenting.

So, YEAH.  Product Management is JUST LIKE parenting.  JUST LIKE.  Especially if:

  1. You go around asking everyone about your baby’s strengths, but especially his weaknesses.
  2. You do win-loss analysis after play dates.
  3. You actively seek market problems that your toddler can profitably solve.  For example, maybe Judd Apatow’s next film could use the CrankyKid’s cursing and new-found toileting skills?
  4. You send out surveys to relatives, friends, members of the local mother’s club, and those “Mommy and Me” Pilates people (or do we only have these in California?) about how well your child is meeting their needs, and what their perception of your child’s brand is.
  5. You maintain a 10-year roadmap for the child, in PowerPoint format.
  6. You conclude that after two years of being a drag on your household’s finances, that you need to shoot your spawn in the head.  Or at least “desupport” him/her by refusing to further feed, clothe or educate him/her.

I love #5. I’m definitely maintaining a 10 year roadmap on my kids.

Subscription Pricing

Saeed at On Product Management has a post cautioning against half measures when moving to subscription pricing.

There is a real tendency if you already have an on premise solution to…ensure you don’t cannibalize the revenue coming in from that solution…always [putting] the existing product ahead of the subscription based product. This is what happened with Siebel on Demand. The existing business had to be protected from encroachment or cannibalization by the on demand business and it hampered the on demand business significantly. Your company will really need to shift it’s thinking to manage this well.

Macromedia published a survey in November [free registration required] that predicts a growing number of software vendors could benefit from this advice. According to the study, roughly half of all software vendors will offer some form of subscription pricing by 2009. Oddly, only 7% of these are doing so in response to customer demand. The most popular answer, 29%, wanted to move towards subscription pricing for a more predictable revenue stream. This is not the type of rationale that will lead to a successful customer adoption.

More encouraging, 21% are using subscription pricing to increase the adoption of their software. Saeed rightly suggests that product managers evaluating subscription models need to look at the overall value proposition and that pricing is simply a tool in delivering on thatproposition . If these vendors are using subscription pricing as part of a different go-to-market strategy or targeting different customer segments, they are much more likely to succeed than the ones who simply want to smooth out their revenue.

The Toughest Part

In today’s Wall Street Journal, Cynthia Crossen states (subscription required):

The toughest part of inventing isn’t solving problems. It’s figuring out which problems to solve.

To me, this is the fundamental role of a Product Manager. When you’re building software products (managed services included) most things are possible. A talented engineering team can probably write code to solve most of the problems that customers face. The question becomes “is it worth it?”

A Product Manager looks for the intersection between technical possibility and market opportunity and guides the allocation of scarce problem solving resources (usually developers) towards the problems that solve the biggest customer problems.

Feature Creep in Firefox

Firefox has become my default browser, so much so that when I recently had to use Internet Explorer, I felt slightly lost.

The tabbed browsing initially drew me to Firefox but I would have say Foxmarks has become best reason to use it. I use two machines fairly heavily, one at home and one at work. In the past, synchronizing favorites was a pain; if I bookmarked something at work, I typically wouldn’t have it at home. Now, Firefox seamlessly synchs bookmarks so I don’t have to worry about it.

Foxmarks is a plug-in that needs to be downloaded and installed separately from Firefox itself. The next version of Firefox will incorporated more of the functionality that used to be provided by a plug-in with the initial installation. There is some concern about this type of feature creep and its effect on performance:

Anecdotal reports of problems, from sluggishness to slow page loads and frequent crashes, have begun circulating in web forums, along with increasingly loud calls for Firefox to return to its roots. The alleged culprit: bloat, the same problem that once plagued Mozilla, the slow, overstuffed open-source browser spawned by Netscape that Firefox was originally meant to replace.

The issue of what should and shouldn’t be included in a product is core to role of a Product Manager. It will be interesting to follow how an open source community like Mozilla makes these difficult decisions.