How to build science-focused product teams

In the last post, I wrote about some general aspects of building science-focused products. In this post, I will lay out a few thoughts about hiring product teams to build these products. Some of these learnings are naturally applicable to any kind of product management, but some of them warrant a special place in a science company. At both Strateos and OpenEye Scientific, I have had the privilege of being part of, hiring and leading truly outstanding product teams, and I have probably learned more from these teams than from any other.

Steve Jobs famously said that the best way to make an organization work is to hire people who are great at what they do and get out of the way. With exceptions, I have always believed this is the right philosophy, but I believe it is even more true for product teams than it is for others. That is because product teams, by their very nature, are highly multidisciplinary. No one person can encompass all the areas of expertise inherent in building a product. This means that product leaders cannot hope to understand every single detail of every team member's job description. Which effectively means that it is imperative to hire people who are experts in their areas and be able to delegate to them.

The essential multidisciplinarity of product teams cannot be emphasized enough. The best product teams are a microcosm of the entire organization; between them, team members contain multitudes. The physicist Freeman Dyson once divided scientists into birds and frogs. Birds can look at the big picture from high above and appreciate the vision; frogs delight in playing in the mud and solving specific problems. I know of no team in organizations that benefits from a pitch-perfect blend of frogs and birds as much as a product team. In its ideal form, it’s as vibrant an ecosystem as a cacophony of birds and animals in a rainforest.

Typically on a science-focused product team, you need at least four kinds of people: a team lead/head of product, a technical product manager (TPM), a project manager and a product and user experience (UX/UI) designer. All of these roles are somewhat interchangeable, but they are still distinct and critical.

The team lead is usually an experienced scientist and manager who has worked in the domain for a while. They need to be a subject matter expert as well, but it's also important for them to not get lost in the weeds of the subject matter; their main job is to communicate the big picture, set vision and strategy, manage expectations and manage up by defending and shielding their team from unwarranted interference. Team leads should also have a good understanding of the business aspects of their trade (business development, sales and marketing), and commercial teams often see product owners as bridges between the business and the technical sides of things.

This is why there must be at least one subject matter expert on the team, someone who is skilled at getting into the weeds and using the product features. One can also “borrow” SMEs from the rest of the organization, but there’s something to be said for having the undivided attention of someone on the team. This person need not necessarily have extensive experience; instead, what's important is that they can do deep dives into specific product features, from the point of view of an end user who in the case of scientific products happens to be a scientist. If they have insufficient knowledge of all the use cases, they would typically also be expected to participate in user research.

The technical product manager's role is indispensable. Especially in the case of scientific product management for both software and hardware, neither the team lead nor the SME are typically engineers. While they may understand the high-level aspects of the development cycle, their main job is to be the voice of the customer and use case experts. That is why hiring a TPM with an engineering or technical background becomes critical. The best TPMs act as a bridge between the product and the engineering teams, translating the urgency and requirements of use cases to the engineers and translating the technical hurdles and timelines back to the team lead and the SME. I have had the privilege of working with TPMs who have more than fulfilled these roles, taking the burden off my shoulders as a team lead in understanding the minutiae of the technical implementation and solutioning and giving me and other team members the freedom and breathing room to do user research and prioritize features.

Because product teams intrinsically sit at the confluence of science, engineering and business, the products they build have multiple dependencies. It is not uncommon for a platform product team to have dependencies on at least two or three other platforms. To manage these dependencies, it is important to have a project manager who can keep all the dependencies in their head, manage multiple timelines and gently but firmly coax the proverbial herds of cats toward a common goal. For this it is integral to hire someone with superb organizational and time management skills (including the ability to course-correct in real-time), a pleasant and persuasive demeanor and an ingrained trait of bridge-building. Often project managers are underappreciated because so much of what they do is taken for granted, and it is easy to forget how chaotic the situation would be if they did not exist. Project managers may also work hand in hand with TPMs and other PMs in keeping track of the sprints and backlog of the product team.

Finally, it is impossible to overestimate the value of a good UX/UI designer. It is easy to misunderstand the role of a UX/UI designer as someone who builds cookie-cutter UIs using standard UI library elements. A designer can certainly do that, but a truly standout designer designs the whole experience - from talking to customers to implementing their recommendations in aesthetically and practically sensible form to convincing developers that there’s beauty in utility.?

The biggest strength the ideal UX designer brings to the table is in being an astute purveyor of human nature. In that sense, just like Dostoevsky is regarded as a great psychologist among writers, a truly excellent UX specialist would be regarded as a great psychologist among designers. To be able to understand and appreciate user needs even before they are enunciated; to plumb the depths of user frustration with clunky UIs; to intuit the unspoken affordances and features that truly delight - these are the hallmarks of great designers.

Product teams in science-focused organizations face some unique challenges. Scientists typically aren’t always thinking about how to productize their work or the tradeoffs involved between scientific rigor and elegance on one hand and things like scale, revenue-generating ability and ease of use on the other. Embedded product teams can ideally bridge this gap. Their SMEs can empathize with the scientists’ needs and ensure that products don’t sacrifice business value for scientific rigor, while the more commercial and technical-minded team members can ensure that customer requirements, scalability and revenue aren’t sacrificed at the altar of elegant science (as Boltzmann once put it, matters of elegance ought to be left to the tailor and the cobbler). Having regular meetings spanning science, product, engineering and the commercial team can go a long way in remedying these gaps.

To make the most of their mandate, product teams should be fully embedded in every part of the organization, receiving input from every department and using it to make informed decisions about features and priorities. In “The Great Gatsby”, the narrator compares Jay Gatsby to a perfectly tuned seismograph that displays a “heightened sensitivity to the promises of life”. Good product teams display a heightened sensitivity to every need of the organization. Teams that are cordoned off from parts of the organization do a disservice to both themselves and the organization at large. The right reporting structure also matters. Typically, individual product heads report to the CEO (sometimes through the intermediacy of a VP or SVP of product), and for good reason: in many ways, product teams touch a combination of technical, business and strategy functions the same way the CEO does; in many ways, the CEO is best placed to have a constant dialogue with them. Other reporting structures can bring challenges. For instance, product teams reporting into engineering can set up an intrinsic conflict of interest since they are supposed to tell engineering what to do based on user research, not prioritize internal engineering features.

Good product teams exemplify the best of an organization’s traits and skill sets. Between them, product teams encompass good technical and scientific knowledge, an astute understanding of business and user requirements, a sure grasp of priorities and timelines, and above all, outstanding communication skills combined with an exemplary sense of what makes an organization tick. Placed the right way and given the right resources and mandates, product teams can take organizations to completely new, productive heights.