Product All the Things

At Pivotal, we often talk about product management as part of a lean practice and our balanced team approach. It's associated with Pivotal Labs and the co-innovation work we do with enterprises. Most think of this as work on new applications, like the Liberty Mutual motorcycle quote app. But what doesn't always come across is how pervasive this mindset is for us. The product mindset shapes what we teach all our customers and how we approach challenges.

At the recent Cloud Foundry Summit in Boston, there were examples of the product mindset *beyond* user-facing applications. From platform operations to security to data, the product mindset transforms relationships between internal groups. Here are some telltale signs of the product mindset at work:

Clearly identified customer: This is obvious when thinking of a company's actual customers. It's less obvious for *internal* customers, within a company. This is about understanding the relationship between two groups: who is the producer and who is the consumer. For example, for operations teams, developers are the customers. With that relationship clear, the product owner can take a customer-centric approach. When that happens, producers' goals are aligned to their customers' needs. When there’s misalignment, organizational dysfunction is the result.  Clarity on those internal customer relationships can refocus those goals.

Product pride: Everyone wants to feel important. Generally speaking, people associate giving orders – not taking them –  with importance. There's an association of status with telling others what to do, which contributes to internal politics. But having a product mindset and customer focus requires a different relationship. It requires taking pride in delivering the best experience to customers. When teams brand their internal offerings and talk about their internal customer successes, they have a product mindset.

This post will highlight some patterns for applying a product mindset to different groups.

Platform as Product

For Cloud Foundry operators, developers are their customers. The platform is their product. And not just Cloud Foundry, but the entire developer experience that they build around it to meet developer needs is the product.

To succeed with this approach, Jai Schniepp of Liberty Mutual advised operations teams to understand users pain points. For example, at one time her new developers felt the pain of waiting 22 days to access the platform. Digging into the root causes, the platform team focused on identity and secrets management. They created a single console for the entire process, abstracting away the different teams involved in developer onboarding. Now those new developers are on the platform within a day.

Similarly, Kyle Campos at CSAA keeps a close watch on the "time to production" metric to understand his developers' experience. The CSAA platform team monitors the time between when code could be running in production (passed tests) to actually running in production. The current standard for their most optimized is 38 minutes.

“That’s pretty darn great for us,” Campos said in his breakout session, “I don’t know that we can do much better than that.” Getting code into production without delay makes it easier for developers to fix any issues that arise.

To learn more about applying a product mindset to a developer platform, watch the replay of the Cloud Foundry Summit panel discussion with Jai, Kyle, and Pivotal's Sean Keery and Kevin Mackett.

Security as Product

Security teams have a tough job. They've earned a reputation at many places as the "Department of No". With the monumental task of keeping a company's data assets safe, security teams see security risks at every change. This creates friction with development teams that face business risk by not changing.

But more and more security professionals are starting to recognize that slowness and the status quo are security risks, too. Patching, for example, is a well-known security best practice that is easier said than done. Many of the exploits from WannaCry or Spectre or Meltdown were because patches were available, but not applied.

So, how can we change the relationship dynamic between these groups while improving security? Although she didn't call it a "product", Molly Crowther has built one for Cloud Foundry vulnerability management. Engineers are her customer. And she is proudly sharing the results of her teams’ efforts at many conferences.

How did her team do it? They started with an "MVP" by opening an email alias to report security concerns. Learning from what people were reporting, the security triage team changed the process for reporting CVEs. After all, making it easier to do the right thing helps fix vulnerabilities faster.

Next, the team went to its customers one-by-one, doing security workshops. These evolved from exhaustive reviews to inspiring sessions. Engineering teams left wanting to make their code more secure. The result? Over 150 security features and updates to Cloud Foundry in less than a year.  As Molly explained, "We get these features out of all the product teams" because they are now enabled and inspired.

Molly and her team embody the product mindset as applied to security. I recommend her longer talk from SpringOne Platform 2017 for more details. It's an interesting model to think about adopting at your company.  

Data as a Product

There have been a lot of questions about how DBAs and data can take part in the agile, cloud-native, DevOps revolution. Developers have seen a lot of progress, but DBAs are often still working the same way they did twenty years ago. Why? Like security teams, they are in the business of managing risk: Data protection, data governance, database availability. That can create friction with developers who want to build and release code quickly.

There's no single solution to this challenge, but there is an opportunity to apply a product mindset. Let's start with datasets. Even before microservices that own the data they consume came along, enterprises dealt with master data management. Customer data, for example, might be housed in several databases. Dates in different formats. Multiple email addresses and contact information for the same user. It's a mess for developers to wade through if they are trying to add a new service or change an existing one, let alone the experience this creates for end-users.

Where there's pain, there's opportunity for a product mindset. Data product managers need to own understanding that pain. Then, DBAs –or, perhaps, database reliability engineers and data engineers–build a product. Developers consume the data they need via an API and all the complexity of aggregating and structuring the data is hidden from them. Data protection, governance, and availability don't go away – they become part of the product.

It's only one aspect of the broader topic about how data and data professionals will evolve. But it's an opportunity to begin to change that relationship between developers and data teams. Adopting the product mindset was one of the only factors that panelists agreed upon at Cloud Foundry Summit.

Unleash your inner entrepreneur… without leaving your job

It's inspiring to hear ops teams and security teams sharing their stories. It's a mark of pride in their work. It's a mark of the entrepreneurial spirit that many of us have… but associate with starting a company of our own.

We need more internal entrepreneurs, building products for developers. What will your next developer product be?