Pivotal Cloud Foundry is a platform that enables organizations to efficiently build robust applications. Companies are learning to embrace digital as a core competency. However, there are high costs associated with building and maintaining software offerings, such as security, availability, scale, and disaster recovery. Pivotal Cloud Foundry abstracts many of these complex problems into simple steps, allowing for organization’s development teams to focus on applications that drive value.
As a Product Manager, I am responsible for setting the vision, strategy, and roadmap to build successful tools for our users to build applications on the platform. The tool that I manage at the moment is Pivotal’s commercial offering of RabbitMQ. I enjoy managing technical tools because they enable users to build a wide variety of end-products that continue to surprise and impress.
8:30 AM: Breakfast
Each day starts off with breakfast in the London Office. Office breakfast is a great way to get to spend time with people across the office, especially those with whom I do not normally have any overlap in our work.
9:15 AM: Team Stand Up
Stand up with the team! This is a quick meeting to cover where we need help, interesting things we would like to share with the team, to discuss salient updates from the previous day, blockers in our path, and plans for the day.
10:00 AM: Product Health Check
Days can get busy, but I protect time to think about what we are doing with the product and why, understand progress against our key metrics, and continually reassess whether the feedback we are getting means we need to change direction at a higher level or evaluate how successful our different initiatives are.
This includes using quantitative data to inform our understanding of product health against key metrics— such as conversion rates, churn rates, and active customer growth. I rely on quantitative data to set the bigger picture and guide where I need to be asking more qualitative questions to understand the trends. For example, if a specific metric along the user journey is not meeting our target expectations, I’ll follow up with qualitative interviews to understand exactly what is going on and which of our assumptions may have been flawed.
During this time, I’ll look through recent customer touch points with myself, other PMs, support, sales, and the field. If there is interesting quantitative or qualitative data, I’ll follow up and make sure I understand the implication of that information.
For example, if I hear from the sales team that a new customer has requested a Proof of Concept for my product, I’ll reach out to get feedback for the new user journey – both for the customer and for how easy it was for the sales team to demo our product. I enjoy working cross-functionally and find it particularly gratifying when we set up another team for success.
11:30 AM: Iteration Planning Meeting
This is a weekly meeting with the team to talk about the work we have scoped for the week. We lead this meeting with a framing of the larger product strategy, and how what we are working on ties into that work.
We discuss both the user value of the work as well as the uncertainty and risks in the tracks of work. By focusing on the outcome and user value of the work, rather than specific implementations, the team can then come up with the best solutions to solve the problem. If we feel, as ateam, that there are too many unknowns (technically or user value) for a piece of work to start work on it, we will come up with ways to minimize that risk.
Spending time with the team is really one of my favorite parts of the day. We have a kind, thoughtful, and considerate group who will push back on product direction, tech health, pieces of work etc. This communication means that our working style is continuously improving, making life a lot better for everyone.
12:30 PM: Lunch
It varies what I do with this time – sometimes I’ll continue my ongoing quest to read all Pulitzer Prize-winning books from the last 20 years, deal with personal emails, or if I’m feeling particularly ambitious, will try to go for a swim or run nearby.
2:00 PM: Scope a feature with the RabbitMQ for PCF team
Scoping is how we refer to minimizing the unknowns to provide enough clarity for the team to pick something up. Scoping starts with understanding the strategy, the user problem we are trying to solve deeply, and then coming up with approaches to solve that problem. A large part of scoping is writing down all the assumptions we are making and checking how sure we are about those assumptions. Scoping looks different for different features and initiatives, but it involves varying levels of user research and technical feasibility work to flesh out the problem and solution space. Currently, we are working on enabling a more intuitive way to configure RabbitMQ to meet the use case and enable a “messaging as a service” experience.
3:00 PM: Coffee and Ping-Pong Break
After a schedule full of meetings, it’s great to take a break and unwind by grabbing some coffee and playing ping-pong.
4:00 PM: Cross-Functional Sync
Since I manage components on a technically-complex product, there is an additional problem-solving aspect to being successful at Pivotal. My product runs on top of the Pivotal platform, which means that the platform team enables and limit what and how we can build. The complexity means that problem solving often has to arc across teams, with us working together to understand the user problem and discover the best possible solution. Recently I worked with a London-based member of a platform-component team and a San Francisco-based team to discuss how to harden the security around credentials used by my product in the platform.
One reason that I enjoy having more opportunities to interact with other teams is because my favorite thing about Pivotal is the people. And working across teams has led me to form some valuable relationships across offices.
5:00 PM: London Product Practice Meeting
Another problem that I tackle with my fellow London Product Managers is how to develop best practice product management in the enterprise space. Having come from a consumer-focused startup, I am used to having plenty of data and advice available to guide my decision making. The enterprise software space is much more complicated due to slow feedback loops— a fact that many end-users do not have direct knowledge of (e.g, each large organization can have dozens of teams and hundreds of users using my product—and limited data collection (due to privacy concerns). This requires creative problem solving on how to effectively validate assumptions, gather data and make decisions.
My most recent experiment was to improve conversion rates amongst application developers. We created a few quick and very simple sample apps to test whether or not readers of our documentation found the premise of a simple sample app interesting (which we tracked by traction of users viewing the apps on our documentation), and which language they would gravitate toward (to understand more about our user personas).
