Kellet Atkinson

Every team is a little different, but based on my experience, generally this is how things typically get divided up: Product: Responsibilities: Feature specs / use-case definition (hopefully, you most of this is already covered in your PRD!) Technical readiness Beta testing coordination (In an ideal world, your beta testing yields some real customer results that can be leveraged by marketing in the initial marketing push) Success metrics definition Internal enablement (Sales, Support) - dependin ...Read More

Generally, the most logical approach is to divide up KPIs according to the user journey, and reserve a few top-level KPIs as shared KPIs. For instance, a generic user journey looks something like: Awareness of the feature -> Understanding its value/use-case -> First Use of the feature -> Repeated use -> Advocacy. In this case, Product marketing would own Awareness and Understanding, and Product would own First Use and Repeated Use, and you may both own Advocacy. Breaking that down fu ...Read More

This is fundamentally a question about driving technical quality improvements through data-driven decision making. Let me break down the approach... First, let's clarify terminology: What you're looking to establish is an SLO (Service Level Objective), not an SLA. SLOs are internal targets for service quality, which is exactly what we need here. To make the case for a checkout success rate SLO: Ground Your Argument in Data Start with industry benchmarks: A quick Google search tells me that eComm ...Read More

When thinking about KPIs, it starts with understanding your customers and the value you expect to create with your product: Think, first, in terms of outcomes Outcomes = What does success look like for your users and your business? A good way to imagine user outcomes is to ask "What would change in our users' lives if this is successful?" This lays the foundation for working backwards towards useful metrics/KPIs When you think you've found a good metric, ask yourself "So what?" Our daily active ...Read More

I'm not sure there's a good, one-size-fits-all answer for this question. OKRs (objectives and key results) are meant to drive behavior change and create focus for your team. I think most teams that use OKRs intend to use them in this way, but fall into a few common traps: Using OKRs as a management tool to drive outputs instead of outcomes If you're like me, at some point you might have been assigned an OKR without measurable "key results" Creating too many OKRs, which completely undercuts the p ...Read More

This is a challenge all organizations face as they scale. Most of my experience is in startups, and I know first-hand how hard it is to transition from instinct to data-driven decisions. It's not something you can just flip a switch on - it takes a very intentional mindset and at least one person to really champion. It sounds like you already have the crucial first ingredient: the desire to be more data-driven. In my experience, there are a few critical steps to take to start to make this transi ...Read More

If you want to create metrics to hold a product team accountable, there are a few things to keep in mind up front: If the goal is accountability, the person accountable should feel ownership - so the process should be collaborative with whoever the accountable party will be. You can't be accountable for things outside of your control. Any metrics you land on should be within the control (or influence) of the PM/team. There are some things that you should keep at the forefront of your mind when c ...Read More