How to deliver customer outcomes, and hit your dates, every single time

Picasso said good artists borrow, great artists steal, and it's the same with ideas for customer success, which is why we're shamelessly pinching some ideas from our sister community, Product-Led Alliance.

While the author of this article, Maggie Crowley, is first and foremost a Product Manager, her razor-sharp tactics and strategies for product teams to ship high-quality products on time that customers love.

So, for all the CS leaders out there – this one's for you too.👇

NB: When this article was originally published, Maggie was Senior Director of Product Management at Drift.

I’m not going to sugarcoat it, shipping is really hard, we operate in an intertwined system that makes it really hard to figure out how to change or sometimes even worse start.

But, having said all that, since I joined Drift, we've never missed a launch date.

My name’s Maggie Crowley and in this article, I’ll share the tactics I use at Drift to ship the right thing on time, every time. Focusing on the four most relevant steps in the product process and tactics that help me hit dates, build company-wide momentum around what we’re building, and make sure we ship the things our customers love.

The challenge here as you know is there's so much wrapped up in what it takes to ship something - shipping is really hard.

You’ve missed your estimate 3x

Maybe you're super confident that you have the right thing going but if you're really honest by this point, you might have doubled if not tripled the estimate that you started with.

Sales just doesn’t GET what you’re building

Or maybe things are humming along but then when you go to start getting excited and telling your sales team about the thing that you're working on, they're kind of like, "Yeah, yeah, that's great but what about this other idea?".

You have no idea if what you’re building will move the needle

Or maybe you're working on a feature or a project that was handed to you from the leadership team, and you have no idea why you're doing it or what the impact is going to be, especially when you have a better idea that you think you really should be working on.

You probably find yourself turning to Google, finding a million articles on whatever one of those problems you're having. But none of them seem like they would actually work at your company, with your specific processing team.

Product advice doesn’t work because it lacks context

That's because product advice almost always lacks context, it doesn't describe all the factors that lead to the success of a given method, because it's a lot easier to write an article about one thing that works than to write an article that describes all the different factors that played into the success without either turning it into a book or giving away all of your company secrets.

We operate in a system

That's because product is really a system. You can't truthfully separate out one part from the rest because it all plays together.

Everything you do, how you operate influences other parts of the system, making it really hard to figure out how to change or sometimes even worse start.

Product is hard

But don't worry, it's not just you, we're all in this. Product is really hard.

Marty Cagan, who's a partner at the Silicon Valley Product Group even gives a talk with this title, which I love. I wanted to call this out because it's important not to get discouraged, and instead to see what you're doing as an ongoing experiment that you can tweak and test and improve along the way.

What I'm going to do in this article is show you the tactics I've used to help with different parts of the system, particularly that helped me:

• Hit dates,
• Build momentum for the company around what we're building, and
• Make sure we ship things our customers already love.

Since I've joined Drift, which is just over two and a half years ago, we've never missed a launch date. This is truly what we do and truly how we work.

My hope is that some of these tactics are useful and you can plug them into the system you're already in.

The product process at Drift

If I were to lay our product process out flat, it would probably look something like this.

These are all the steps our product teams go through to ship something, and in this article, I'm going to focus on these parts of the system…

As they're most relevant to shipping things on time and building momentum, with the added benefit of you not needing to change your entire process for them to be useful.

First: a note on hitting dates

I want to start with dates. You'll notice this wasn't listed as one of those steps above and that's because hitting dates has to do with how you organize your team when you get started.

Hitting dates means hitting the date of your overall mission, which might be your goal for the quarter. It also means hitting all the little dates you have along the way. You're going to have to be able to hit those dates, of course, to hit your big macro date.

There’s a secret to hitting dates

Luckily, it turns out that there is a simple, although not easy secret to this process.

It’s not about the feature. It’s about the outcome.

You have to avoid thinking about the feature when you're setting the date and instead, you have to focus on the outcome.

What you really need to get started with this are two things. You need a story and a date.

The story

The story is the problem that you're solving. But the story shouldn't be something high-level like 'my users need to be able to log in, and like understand what's going on'. It should be really specific - you should know exactly who you're solving for.

I'll use Drift as an example. We sell into marketing and sales teams, so I could say “The marketer needs to log in and do X”. But that's not enough.

• Is it the CMO?
• Is it the VP of Content?
• Is it the director of Demand Gen?
• Is it a Social Media Marketing Manager?

The more specific you are about who the protagonist is of your story, the more constraints you're going to create for your team, which is going to increase the likelihood that they're going to ship the right solution when the time comes to get there.

The date

You have your story, and you have to pair that story with a date. The date is how you understand how much the project is going to be worth to your business.

The date you set is a constraint that's going to have a huge impact on how your team thinks about the solution they're going to build.

Because obviously, there's a big difference between setting a date that's a week from now versus setting a date that's six months from now.

Fixed time and variable scope

Ryan Singer, who's the Head of Strategy at Basecamp, tweeted this really great diagram recently that I loved on this topic. You can think about the story and the date as the sort of box on the left.

It gives you a set of hard constraints, that once the team understands those constraints, they spend their time discovering the solution within the context of the story and that date.

Versus if you forget to set a date or if you instead focus on the feature, instead of giving your team those constraints, you end up on the right, where you have this problem and then your scope continues to increase and increase and increase.

To help solve that problem, to help solve the problem of your dates always slipping, if instead you give yourself a fixed time, and variable scope, that's how you're going to be able to hit those dates day in and day out.

Example

I'll give you a more tactical example. Especially in B2B, it's really common to have a project that's about helping customers understand what's happening, that's typically a report.

It's really easy to see how a team would start with this problem and say, "Okay, well, they need to understand this metric. This metric has to be filterable by time, but then they have this other filter, maybe by geography, and then every customer is different, so they should be able to customize it".

And you can see how your scope is going to continue to get out of control when you're working on this problem. But if you're being honest, you can probably also solve the problem by writing a SQL query and emailing your customer a date.

That's why the date is so important because it's going to determine how far the team goes in solving the problem. Ideally, what happens is the team ships the email, they run the SQL query, then they start building on that and building on that, so by the time the date comes to pass, you shipped several increasingly better solutions to their problem over time.

That's the real secret to hitting the date is you have to have a story that is specific and relevant and you have to have a date that matters, which means you have to have a fixed time and a variable scope for the feature that gets delivered.

Hitting dates isn’t about estimates

One thing I just want to extra call out is that hitting dates is not about getting an estimate right, if you notice I didn't talk about you sitting down with your engineering team and doing estimates.

If you end up picking a date and mandating what your features should be, you're going to get stuck in that land of story points and sandbagging your estimates, and constantly missing your dates.

That's just a terrible place to be and no one wants to be there.

Next: the story

Picking the JTBD

Now that we know we need a story and a date, we have to figure out what the story is.

Put another way, the story is actually the problem that you're going to want to solve.

Which problem can you solve that will have the greatest impact on the mission?

So at Drift, we use the jobs-to-be-done framework, which boils down to, what problem can you solve that will have the largest impact on the mission that you set out to achieve.

This can be a little bit fuzzy, and the mission is typically a goal. Maybe you have OKRs, I'm going to assume you have some kind of guiding principle about the stuff you're working on at your company.

First, talk to your customers

The key to getting a tight job to be done is a deep understanding of your customers. It's the number one most important place to start.

You have to talk to them. You have to talk to them live, you yourself, have to talk to them as a product manager.

I want to have a quick sidebar on this - we have a Slack Bot that asks us every Friday, how many user exposures we had each week, and I expect to never personally have a zero.

What I mean is truly for the entire year, excluding PTO, a week should never go by without me speaking to a human being who is my customer.

If you're at a company that doesn't allow you to do that, and you're a product manager, I probably would quit. Because to me, this is the absolute best way to understand what you should be building.

Let's assume that you're talking to customers and this is an example of what you might get from one of those conversations.

This is something a real customer actually sent me when they were trying to describe what they wanted from my product, they went out and they built a workflow to explain to me what they were trying to do and how they expected it to work.

This is gold.

Because remember, if you're in one of those positions where you're building something that you maybe don't super believe in, then you have these other ideas, imagine being able to go to an executive and instead of saying, "Hey, I think this idea is really good".

You can go to them and say, "Hey, this is exactly what the customer wants. This is exactly the problem they're running into. And here's how we can fix it".

Talk to the customer team

So, you've talked to your customer, but it's time to expand that coverage. I think talking to the team that spends their whole day talking to customers, the CSM team if you have one is a really good way to broaden out the knowledge that you're getting.

One tactic we have is again, a Slack bot, it pings our team once a week with a topic we're curious about, and it gets their feedback.

Instead of you just going out one to one and asking different people about their interaction with the problem, what this allows you to do is crowdsource that knowledge and you end up seeing a really rich discussion between those people, which can be really helpful.

Engage as many people as possible

We also just started a couple of weeks ago, testing out a board where people can write up customer pain points to see if we can engage even more people at the company in this discussion.

This has really been great for visibility and again, is just a tactic to help you understand the full scope of a customer problem. If you ever feel like the people you're talking to are only giving you part of it, this is a good way to broaden out your understanding of that problem.

Summarize into the JTBD

Once you understand your customers and you know your mission, from your goal-setting process, you can smash it all together and summarise it into a really crisp story that describes the problem that you're solving.

A typical jobs is going to follow the framework of it has an X, I want a Y so that I can Z.

But personally, I believe in taking a lot of editorial liberty in telling a story, because you never know what part of that story is going to strike a chord with the team and inspire them to think of an idea.

What's important to remember is that it's a story, it describes the customer problem in really specific detail, including why that problem matters to the customer. And it still does not and should not talk about the solution, you still haven't picked your features, meaning the scope at this point is still variable, you're still on your way to hitting your dates.

Should be able to answer

At the end of the day, when you're done doing this initial research phase into the jobs to be done, you should end up in a place where you can answer this set of questions.

If you're not able to answer these with specificity and clarity, it's going to be unlikely the team is going to head in the right direction, or even worse, they might ship something amazing, but it might not end up being as relevant for your business as it should be.

So these are the questions you can ask to make sure you're on track to not only build a high-quality product but one that matters for your business and the market that you're in.

I'm spending so much time on this part of it because to me if you get this part right, if you define your problem well, if you're super clear, very specific, you have lots of good customer anecdotes, everything else downstream of this is going to be easier because you're going to start with a much deeper shared understanding of what you're trying to accomplish.

Storytime

Let's say you've done all this stuff really well, you have your problem, you really know what you want to tackle. The next step is to storytime.

I want to talk about this because I think it's something that everyone can try, regardless of the system you're in because it's just a meeting.

What questions need to be answered in order to solve for the JTBD?

Storytime is how you transition from the problem space to the solution space. It's the start of all that great design research we know and love and above all, it's really about bringing your team along for the ride you've already been on if you're a PM doing that initial research.

The goal is to figure out, what would you need to know in order to solve for the problem that you've identified.

In the room, it's a meeting of probably 30 minutes to an hour, you have to bring the whole team that's going to actually work on the problems, that's the PM, hopefully, your product designer, hopefully, the actual engineers who are going to work on it, ideally, you'd have someone from customer support or customer success.

What you do is go through the problem, go through your research, really tell that rich story about the customer, and then you develop open questions that have to be answered in order to solve the problem.

Basically, your whiteboard should be full of comments that are like:

• What would it do?
• What's it gonna look like?

Maybe there's a technical complexity you know about, and you can ask questions like:

• Is this possible?
• What are the different ways we could approach this?

Then you start to brainstorm and move from problem to solution.

Output

You leave the meeting with a list of open questions and the key here is you assign them with dates, of course, to every single member of the team.

They go off for a day or two, maximum a week and they come back and you share what you've learned and you do it again.

What you're doing is engaging the full team in discovering the solution. It's not that a PM is writing a spec and handing it over, the engineering team is ideally engaged in the solution.

This is where you refine that scope

That's really how you start to narrow the scope down, by answering open questions, you're starting to figure out exactly what the solution is going to look like, it's going to meet the constraints. You can go off on your merry way.

I'm going to skip over the design and build that's a really hard thing to change if you're not Head of Product. For the sake of this article, I’ll assume you built it or you're in the process of building it and the next step is to make sure it actually is going to meet your customers needs the way you thought it would.

Early access

How to make sure you ship what your customers love

We use a tactic called early access, which means picking a small handful of customers to partner with to finish building the thing that you're working on.

Heaton Shah created this diagram that I think says it best.

Early access is about engaging your customers and partnering with them versus giving them an early buggy software that might miss the mark.

The framing matters a lot here because it's going to help you engage your customers in the right way. It's going to help them feel like they're a part of the thing you're building, it's going to get them really motivated to participate in this process with you.

Real-life goal

Here's an example of a goal that a real team had set for themselves with their early access program.

The important thing I want to call out here is you can't just test with a group of people and then launch when the date comes up regardless.

You have to change what you're doing based on their feedback, you have to leave time and space, and especially emotional space, to allow for your customers to decide what you're doing is not exactly what they wanted.

Selecting the right customers

Because you're going to need to change things, you need to be really careful with the customers you select to participate in this process.

This might seem obvious, but it's important to call out they should:

• Represent your target persona for your business.
• Be willing to use something that might break because it is early,
• Be willing to give real feedback - try really hard to avoid the people who are always like, "Yeah, this is great".
• Be open to speaking publicly about using your product.

Start with the customer team: they always know who the squeaky wheels are

I always ask my customer teams for recommendations because you never really know how an early access program could help with a churn risk, it could help with an expansion opportunity, or it could just get someone really excited and turn them into an evangelist, especially if you're not in the B2B space.

Example #1

Here's an example of a real email that I actually used in soliciting some participants for an early access program.

What I'm asking in this email is for someone to use the product without me there and to film themselves using it. I did that because I wanted to weed out the people who weren't willing to participate and put some time into the program because you need people to put the time in. I also didn't want to bias the feedback they were going to give me.

I got some really amazing and hilarious videos back from this so it's just another tactic that you can use.

Example #2

Here's another example where I'm a little bit later in the process of an EAP and I'm asking like, "Am I hitting the mark? Am I getting close to getting that l10 out of 10 feedback?".

The key here is honesty. I'm asking Brian to give me a rating. You'll notice this is a picture of Slack - we have shared Slack channels with some of our customers to help facilitate this process, which means I can DM Brian and ask him how he feels about this product. That also means that he can DM me.

Really know your customers

The thing I want to call out here is you should really know your customers. This is Rob, we worked together to build Drift Automation, which is a product we launched last year.

He's actually changed companies since then but he went to another company that uses Drift and the same products because it's part of how he wants to do his job. He sees himself and he truly is a partner of ours and how we're building our company and our products.

You have to get personal

This is an example I want to call out because you have to get personal. Your customers in my opinion shouldn't be like abstract beings that exist in some persona document that floats around your wiki.

They need to be real because the more real your understanding is, the more specific and useful your stories are going to be that you're going to write with your teams.

Don’t make assumptions

No matter what the reality is of your customers, they're always going to surprise you. They're never going to be as perfect and straightforward and easy to understand as a persona.

No matter how long you do product your customers are always going to keep surprising you. I just wanted to make sure to say don't be arrogant. Don't assume that you know what your customers need, just spend the time to talk to them, because it's always going to be worth it.

Do your customers like it?

So, you've been talking to your EAP customers, you've been iterating based on their feedback, in my opinion, the last thing you need to do before you can move on and launch publicly is to not only make sure you've solved for that job to be done but to make sure your customers like it.

I think you should be getting feedback like this.

This filter is really hard to articulate in a spec, but try to look for it and it matters because this attitude is how you know you're starting to hit the mark on what you're doing, you're building something that's going to be exciting enough to drive your business forward.

Ship it

How to build momentum through launch

By that point, that means you've hit all your gates, everyone's super excited. You're getting 10 out of 10 on your EAP it's time to launch publicly and this is where that product-led magic really starts to click into place.

Launch by telling the customer story, not the story of your product

Because this whole time, you've been super focused on your customers, you've done all that research, you’ve storytime’d, you've done an EAP, you've partnered with your customers, which means when it's time to launch, you have all of their stories, you already have case studies, you should already have results.

As a product team, you end up going to your go-to-market team, with all this ammo for them to use to build the business. Ideally, you've hammered that customer story home so many times that the whole team should be able to tell the story.

For example, at Drift, when we release something the engineers who worked on the product post their work in a Slack channel called Shipyard, and every single one of them always can articulate the “why”, can articulate who it's for, and why it matters.

When we launched Drift Automation, as I talked about before last fall, the materials we used were all about the person we were building for and the problem they were experiencing.

None of this was about the technology that we were building and it was really cool. It's really important at this point to tell that customer story over and over again because it's going to be super relevant for the people that you're trying to sell to.

Limit the release, build excitement

Another tactic, because a lot of the pushback you might get, especially if you work in the enterprise space as well, this is all well and good but enterprise customers move slowly, they don't want to accept change, they don't want to be part of an EAP.

One thing you can do is to launch publicly, but then limit the release.

Because if you've done a good job, if you know the story, if you really understand the problem you're solving, it's going to be relevant for those customers.

Then all of a sudden, you're flipping the script on them and saying, actually, you can't get access to this thing yet, and then all of a sudden, you get stuff like this.

These are all examples from enterprise customers saying, "Wait, actually I do want to participate in this". So you can build FOMO and even engage those customers that you might feel don't fit this kind of paradigm.

At this point, you’re a hero, you shipped the thing, but of course, we're not done.

Learn and iterate

Keep the momentum going after launch

You have to ask whether it worked. I think about this step as really keeping the momentum going and to do that you have to keep learning.

It's definitely not enough to this process once like I said, at the top, this is a system. So reps and sets are what's going to matter and this moment is really how you refine your understanding of your customer so that your next story is going to be even better.

Evaluate

I think there are three distinct questions you have to ask after you ship something:

1. Impact: did you move your KPIs?

You have to understand whether it hit the metric that you set - so definitely have a metric that you set before you ship something.

1. Behavior: how are customers using it?

You have to understand if it works the way that you expected, if are your customers using it like you thought they would.

1. Sentiment: do your customers like it?

Answering these three questions is going to give you a much better, richer understanding that you can use to improve the system the next time you go through it.

The other great part about this is that you can answer these questions regardless of what your product development system looks like. Even if you have to do it in your spare time, this can be done by anyone.

Especially if something didn't go well if you missed a deadline or something, if you're able to answer these three questions, you're going to be a hero for your leadership team when you go and give them that data.

To summarize

I have thrown a tonne at you, I've talked about hitting dates and jobs to be done and storytimes and EAPs but you don't have to take my word for it that this process works.

Here's a direct public quote from Adrian, another customer I work with and this tells me we probably spent just enough time with him.

While he is joking, I think, he's also part of a very public case study describing the impact of using the product that we built had on his business.

This is the kind of result and the kind of relationship you can get if you try to start following this process.

It’s okay, this is hard

Product is really hard. It's hard to get this right. It's hard to make sense of it, even when it feels like every part of the system impacts every other part of the system, and you don't know where to start.

But I'm hoping that you read at least one thing in this article that sparks an idea for you, that you can try in the system you're in because when you get this right, you can drive your whole business forward by telling the right stories and shipping the right things.

I'll leave you with three questions to get your mind started and thinking about what you could do.

Please don't forget to evaluate what happens and use that to improve what you do next time. Do this a couple of times and you're going to be lightyears ahead of the people around you and other businesses.

Thank you so much.