6 Months and 6 Lessons in Product Management
Six months ago, I joined the Product Management team at PartnerStack. I was coming from our Customer Success team, and I was excited to see another area of the business and learn new skills. My team is focused on reporting/ analytics, and we were tasked with building our in-app reporting/ analytics suite. For someone who enjoys looking at data, this was a great opportunity and challenge that truly excited me.
Since I knew the product and space quite well, I was able to jump in and start running customer interviews right away, but other areas of the role (such as running sprint planning or backlog refinement sessions with the team) took time to learn. The first month was one new thing after the other, and flew by as one might expect in a new role.
While the learning curve in those first few weeks was quite steep, I’ve learned even more since, and I thought it may be fruitful to put the ideas down on (virtual) paper.
Here are the six takeaways that stuck with me:
- Use your team… more collaboration = better output
- Interviewing 101 — gather your insights from the right questions
- Encourage customers to get real about your product
- Deadlines help make things simple
- Lower the bar for your MVPs and get them shipped asap
- Don’t just celebrate the release — celebrate the adoption
This article is meant to highlight just a few of the core lessons that I’ve learned as a Product Manager so far. Some may be more specific to product management, where others are universal. In each section, I’ll outline briefly why each lesson is important for me, and then what I/ my team has done, or is doing, as a result. By no means is this list exhaustive, so if there’s something you feel that is left out and deserves to be on here, let me know in the comments!
Use your team… more collaboration = better output
No surprises here — working with my team rather than siloed from them has made for more accurate timeline estimates, project requirements that are better defined and scoped, and a stronger shared understanding of potential roadblocks and our customer/ business goals.
However, as much as I expected this, it took me some time to understand its full value. My original thinking was that all meetings with my engineering team took time away from their ability to complete work or research ways to achieve our goals. In reality, having biweekly 30 minute or hour long syncs can save hours of time of back and forth in each sprint.
What we did: My team always had biweekly backlog refinement sessions where we reviewed the upcoming tickets, assigned effort points to each, and discussed potential blockers… but these didn’t allow us to dive deep into some of the larger unknowns. So we added an extra biweekly 45 minute sync with a single senior engineer so we could study these issues in depth without taking up the time of the entire team. Our awesome product designer and I now dive into the vision that we have for a certain feature, learn more about the technical requirements, prerequisites, and potential roadblocks from our senior engineer, and even start to assign some effort points to some of the trickier tickets — which makes it so much easier to effectively plan and organize our sprints, knowing that I’m not missing anything major. Ultimately, this means that less work gets pushed back or rescoped mid-sprint.
Interviewing 101 — gather your insights from the right questions
It’s easy to interview a customer, it’s hard to do it effectively. When I say effectively, I mean getting real insights that can help you move your product/ business in the right direction, while avoiding the traps of building fruitless or simply “nice-to-have” features. For myself, working on a team focused on analytics and reporting, there was every opportunity to fall into one of these traps. Vague customer input was often the culprit; every customer would “love for reporting to be improved”… but what does that really mean? Not much, unless you dig deeper into the details.
In fact, getting those details is something both so important and often done wrong, that it’s one of the first suggestions I make to anyone looking to get into Product Management. Prospective and new PMs often ask “What can I do to improve my skills before moving into the role?”, and improving customer interview skills is always the first thing I say.
Think of the typical starter questions that you may hear or see… “Would you use product X?” or “Would you like it if we made problem Y easier?” or “Do you want to pay less for Z?”. While these are potentially helpful questions to guide your research, they aren’t the basis for gauging real user/ customer interest.
What I did: On my first day as a PM, my boss recommended I read a book called The Mom Test. It was all about asking questions that uncover real user experiences. It was so helpful in learning the customer interview style that eventually helped me pull together the scope and requirements of my team’s first few releases. I now recommend it to everyone who asks about customer interview techniques!
Encourage customers to get real about your product
One of the specific learnings from The Mom Test and other readings was the need to create an environment where customers believe that I care about improving their experience, rather than just hearing praise about my ideas. While of course I know this to be true about myself, it’s difficult to create that environment with a customer that I’ve never spoken to before.
What I do: When I am in an interview and I get the sense that a customer is pulling punches, I will explicitly invite them to be more harsh. I often say something along the lines of “I won’t be offended if you really don’t like something — I want to make your experience as great as possible, so hearing about what isn’t great for you is super important to me”. That line shows the customer that I really am looking for honest feedback, and giving it is aligned with their interests — improving their experience with the product. It really helps get the conversation flowing.
Deadlines help make things simple
Everyone hates deadlines. But in my new role, I’ve found that they have actually made my life easier.
As a PM, the main thing I’m responsible for that has a hard deadline is our sprint plan. Since we operate in two-week sprints, the deadline that I set for myself for the next sprint plan is typically one or two days before our sprint planning session.
I have no problem lining things up in time for each biweekly sprint planning session, but I have found myself struggling with building up enough of a backlog to go further; to cover the next few months worth of work, rather than just one sprint out.
What we do: Our product team has a monthly backlog review meeting, where each PM goes through the larger themes in their team’s roadmap and deep dives into priority tickets. The expectation for each PM is that we have fully detailed tickets for the next 2 sprints, and 3–5 sprints (1.5–2.5 months) worth of work planned out at a high level.
This has helped me keep organized, but also make sure that I’m keeping things simple; it gives a chance for the whole Product team to hear what I have lined up, and call out opportunities for me to cut scope and make things clearer for my team, while still delivering the intended customer value.
Lower the bar for your MVPs and get them shipped asap
Outside of work, when I hear MVP, I think of Lebron James, Steph Curry, or Jared Dudley. In this case, though, I’m talking about a Minimum Viable Product. It’s a term that’s often thrown around in the tech scene as jargon, but is actually a very important concept. The idea is to build the most basic possible version of your product or a feature, push it to users, get their feedback as soon as possible, and iterate. Imagine the opposite:spending months working on a feature, only to release it and learn that your customers actually wanted something else. That’s no fun.
What I learned is that perceptions about what is really minimum viable can vary between teams. In particular, Customer Success (CS) and Product have very different expectations on what’s needed to ship a feature. While I was in CS, I generally understood the idea of an MVP, but I also wanted to ensure that we provided a good customer experience at every turn. I wanted to bring that perspective with me when I became a PM.
Once moving to the Product team, however, it only took me a couple sprints to realize why it was SO valuable to push features sooner — even if it meant a temporarily sub-optimal customer experience. First, releasing a feature in weeks allows you to get feedback on it much sooner (as opposed to keeping it as a concept, or getting feedback on mockups with your beta users). Second, you can use that feedback to guide the rest of your build, so you can adjust without having to redo everything. Third, it’s motivating for your team to see the awesome work they pump out get used sooner!
What we did: Keeping in mind my desire to balance the customer experience with the need for “minimum viable” releases, I held back releases until multiple pieces of functionality were added. Over time, I learned to meet in the middle: release regular MVPs to our beta customers sooner rather than later, so we could get feedback and work out kinks with a small group of users and then deliver a strictly positive customer experience when we released to a larger audience. At PartnerStack, we have a handful of awesome customers that have volunteered to be part of our beta testing program. I work so closely with these customers on new builds now, that I’m sure any one of them could tell you what is coming up next from my team.
Don’t just celebrate the release — celebrate the adoption
Celebrating a release of a big feature is important — you’ve spent months figuring out the experiences core to the user’s needs with respect to the feature, your team has worked hard on designing, building, and testing, and you’ve finally gotten it in front of your users. Definitely celebrate that.
More important, though, is to celebrate the adoption. Even if you aren’t explicitly celebrating adoption today, you should already be tracking usage metrics — so now all you have to do is share them as a team, and highlight once you’ve hit your milestones. If you’re not tracking usage metrics and want to start, then how are you judging the success of a release?
Tracking usage metrics for your release is something you should be doing today (even if you aren’t currently celebrating adoption) — but celebrating these milestones as a team will give a great recurring feeling of success after the initial release.
What we did: Our team launched a full analytics suite for our customers the other month, and have since kept an eye out for success metrics like load speeds, number of visitors (unique and total), and how many pages within the analytics suite those visitors are going to. I combed through the data recently and compiled a list of highlights and shared them with our team on Slack. I pulled this data month over month, as well, so we could see how the usage has changed since the initial dataset. It was so motivating to see hundreds of users look at our feature daily and also insightful to see the user behaviour after the launch.
If you’re not tracking usage metrics but have been wondering how to jump in, start by thinking about what metrics determine when your customers succeed. Work with your CS team to understand these… Are they looking at analytics twice a week? Are they inviting three new teammates monthly? Are they reaching out to support more? Less? From an ex-CS team member, I can confidently say that your team will be able to point you in the right direction!
While the last 6 months taught me a lot, I feel like without the above six pillars, I’d still be lost in the role. I’m definitely still learning — and I’m glad that I’ve got a sharp and supportive team that’s there to help me as I go. If you’re interested to hear more about moving into Product Management or specifically from Customer Success to Product, feel free to find me on LinkedIn and reach out! I’m always happy to chat.
