Caroline Hane-Weijman
PRODUCT MANAGER, PIVOTAL LABS, NEW YORK
I found Pivotal Labs… through a friend of a Product Manager who worked at Pivotal Labs. I had breakfast with her at the office and got to experience our morning, office-wide standup. I remember I immediately sent my friend a text message saying I wanted to work here! It seemed like an awesome culture.
I decided to join Pivotal Labs because… the collaborative and flat culture I saw really appealed to me. And when I asked around, everyone thought of Pivotal Labs as a leader in agile software development and product management practices and pointed out how much I’d be able to learn. Pivotal Labs has so much accumulated knowledge, great practices and knows how to create talented, agile product teams. I was also excited to be able to work on different types of products. In my previous role I wouldn’t had been able to work on web and mobile, because those were different parts of our organization. Here, I can do that.
I am currently working on… a subscription payment platform.
9 am: Morning Stand Ups
My day starts with breakfast in the office with other Pivots and clients, and then office standup. Office standup is always right after 9 am. It’s very invigorating and a great way to start the day. It reminds you that you’re part of a community.
My team’s daily stand up is at 9.15. Our team consists of 9 members: me, a client product manager, a Pivotal designer, two Pivotal engineers and four client engineers.
Our client is a payments provider. We are helping evolve their existing subscription payments platform. The current solution is fragmented across multiple systems. We are designing and building a new system that will integrate into an existing ecosystem to leverage existing functionality while enabling customers to access one unified system for their solutions.
We are currently in the midst of Discovery and Framing. It’s a process that helps us get to a shared understanding of what we’re building, for who and why. We start by understanding what unaddressed or underserved problems or desires our customers have, before we start to think about what solutions we could build.
One of the most important things we do this stage is identify and test our most risky assumptions about the users, the feature set, the technology and the business model — assumptions that, if we get them wrong, might put the entire project at risk. This helps us gain confidence in what we plan to build first so that we don’t waste design and development cycles building features that no one will want to use. Sometimes we learn that we shouldn’t be building any software at all, and that’s a valuable outcome too. It means we’re not building software that shouldn’t be built.
10 am: Planning for Product Inception
Our team has put together a list of questions that we want to answer this week, before we incept. Inception is our starting point for development. The product team and our stakeholders get together and define the initial backlog of development work together, based on what we have learned during the initial Discovery & Framing and on what the project goals are.
If we answer these questions, we will have enough confidence in our feature ideas to feel comfortable committing them to code. For instance: How do we define success from a business perspective? What merchant segment is most accessible and valuable for the business? What are the highest value features for merchants? What does the competitive landscape look like? What does it mean for developers to have an easy to use API? Are there dependencies on other teams that we need to get ahead of? What’s the right tech stack for this app and team? Do we have documentation for all the integrations we expect?
I am going to collaborate with Francisco who is the designer on the team, and my client PM to do user research to help inform what features we should build and in what order. I will work closely with my client PM to make sure that we understand the business needs driving this initiative, to inform our strategy for the product.
Meanwhile, the engineers will work on drafting a very high level systems diagram so that we get ahead of reaching out to the client teams whose services we will depend on and systems we need access to. The systems diagram will also help us decide what tools we’ll need for development.
11 am: Customer Interview Prep
I’m collaborating with Francisco and our client PM on preparing today’s customer and stakeholder interviews. We have 5 interviews scheduled for today and 4 for tomorrow. By the end of this week, we will have done 14 interviews with a mix of merchants who are existing and prospective customers of our client, as well as internal client stakeholders from sales, account management, and solutions implementation teams.
This first round of user research will be focused on informing the feature set we should be building for our first release. We need to understand the needs of each customer segment as well as how important that customer segment is for our client’s business. We also need to understand the business’ capability of selling a solution to that customer segment. Even if we were to build a solution tomorrow for one of the customer segments, we wouldn’t necessarily be able to sell it. So, we need to define a very narrow focus for the first version of the platform we’re building, and make sure it’s a validated high value opportunity that can be realized by our client’s organization.
In the interviews, Francisco, the client PM, and I will take turns leading the interviews and taking notes. One of the engineers on the team will sit in so that they can see the process. It’s important that everyone on the team understands who we are designing the product for, and what those people want or need from it.
12 pm: First Customer Interview
We got some early signals from our first interview that several of our user assumptions are valid. We also learned some new and interesting things about how unaware customers might be of our client’s offering, and that they need more handholding during the sales process than what we have assumed.
If this feedback is consistent, an intuitive API won’t be enough. We’ll need to think about how to create an experience that helps the customer become aware of the full breadth of our client’s offering. In addition to the sales process, we will need to explore how documentation and a sandbox environment might impact the user experience. We also assumed that customers are familiar with certain concepts and naming conventions, because they are industry terms. Turns out they had no idea what these things mean.
Another interesting early observation is that customers don’t know their pain points if they haven’t experienced anything else than the platform they’re currently using. They haven’t vetted other solutions because they already have a great sales relationship with our client. They either consider building a solution themselves or going with our client’s solution. They haven’t considered the competition at all. So, we’re learning that our end users aren’t comparing us against other products; they don’t know what they don’t know.
12.30 pm: Lunch
Today is one of my favorite lunchtime activities — PM Article Time! Jim Thomson, one of the PMs in the NY office, sends out two short articles or videos in advance that showcase product development practices at other companies or from different thought leaders in the industry. Pivots and clients across design, PM, and engineering then get together over lunch (usually sushi!) and discuss. These lunches have generated really interest conversations and ideas for how we can improve our practices. It is important that we learn from others and don’t become an echo chamber.
1.30 pm: Second Customer Interview
We’re preparing for two interviews starting at 2pm. First, we’re talking to an internal stakeholder who heads up the IT solutions implementation team inside of our client’s organization. After that, we’re meeting with business line lead from one of our client’s customers.
3.00 pm: PM Practice Time
We’re taking a 30 minute break from interviews, so I’m working through a couple of tasks related to our Product Management practice in the NY office. We think a lot about continuous improvement when it comes to how we work. An important aspect of that is sharing our experiences with other PMs at Pivotal Labs and with the broader product community outside of our own company.
I recently attended a Women In Product meetup hosted by Capital One Labs, that I really enjoyed. Their head of design strategy had interesting experiences to share about iterating on their teams’ agile process. I am doing a quick writeup of my thoughts that I am sharing in our NY PM slack channel. I also take a few minutes to laugh at the daily gifs that are shared.
I’m also working with a designer in our office to set up a series of lunch talks about our Discovery and Framing practice. I’m writing a draft email to the PMs and designers in our office that I want to run by her before I send it out.
4.00 pm: Interview Synthesis
We’ve completed four interviews and are summarizing what we’ve learned so far today.
It’s really important to remember to develop deep empathy for the user — to feel with them, rather than for them. We may think we know that features to build, but unless we spend time with the people we’re building for, to really understand what is important to them and what they’re trying to accomplish, we’re going to end up making a lot of risky guesses. That’s why it’s so important that we constantly test our ideas, and use data from research to inform our decisions. For example, our client had come in with the assumption that building this one particular feature was the most important thing for the team to do based on conversations with a large prospective client. After talking to the business line lead, we not only learned that this feature may not satisfy the needs of the customer but that the sales process was in early stages and discussions regarding detailed features would not be had for another 4–6 months. We can build other features that could capture smaller merchants in a shorter time frame.
However, at the end of the day, our team doesn’t set the strategy for this product. This is one of many solutions that our client offers in their portfolio and there are many pieces that need to fit together in order for the client to move towards a high-level strategy for their business. It crosses product, engineering, DevOps, sales, customer support, etc. We need consider all perspectives as we make recommendations for and decide on product priorities.
5.00 pm: Team Sync
We’re all getting together to sync up on what we’ve done today. We’re also going to do a quick retrospective of the day and do a recap of the two different tracks of work; the user interviews and the engineering working sessions.
While Francisco, the client PM, and I have been talking to users, the engineers have been doing high level systems design. They’ve focused on the scheduling system in particular as we will need it to support a specific feature we know we need to build. They’ve also worked on getting our development tools and environments set up with pairing stations, CI/CD and github.
6.00 pm: Time To Go Home!
I just finished writing a email for our stakeholders to keep them up to date on our progress.
The first thing we’ll do tomorrow is to continue synthesis from our user interviews and map what we’ve learned to the different customer segments to see if there are any commonalities in terms of user needs. This will also help inform any changes we want to make to our questions for our interviews tomorrow. We want to get to a clearly prioritized and validated feature list this week, so that we can review the features with our key stakeholders before we incept next week.
But that’s for tomorrow. It’s 6 pm and time to go home and cook something fun!
Pivotal Labs is an lean + agile software consultancy. We collaboratively build and design mobile and web apps for the world’s largest brands.
If you’d like to learn more, please visit our careers page.
This profile of Caroline Hane-Weijman was written by Joanna Beltowska.
Other parts in this series:
- A Day in the Life of a Product Manager at Pivotal Labs
- A Day In The Life of an Engineer at Pivotal Labs
- A Day In The Life of a Product Designer at Pivotal Labs
Follow us on Twitter
Visit our careers page
A(nother) Day in the Life of a Product Manager at Pivotal Labs was originally published in Built to Adapt on Medium, where people are continuing the conversation by highlighting and responding to this story.
