Maggie Crowley gave this presentation at the Future of SaaS Festival, when she was Senior Director of Product Management at Drift.

If you're looking for a sugar coated fairy tale, you won’t find it in this article. This is designed to be a real no-nonsense guide on how to ship on time, every time.

Forget the bells and whistles, we’re gonna zoom right on the hard nuts and bolts that make the process run smoothly.🔎

Aims of this article

When I say nuts and bolts, I'm talking about tactics, of course.
I'm going to share:

• The tactics that I've used to help with different parts of the system.
• The tactics that helped me hit dates.
• How to build momentum for the company.
• How to make sure we’re shipping what our customers love!

Since I've joined Drift, we've never missed a launch date. The results speak for themselves!

My hope is that some of these tactics are useful, and you can effectively integrate them into your organization. But before we go into the solutions, it’s probably best to look at some of the common issues around this topic.

Challenges for shipping on time

Make no mistake, shipping is really hard. And maybe you're super confident that you have the right thing going. But, if you're really honest, you might have doubled, if not tripled, the estimated timeline that you started with.  

Or, maybe you start getting excited about an idea, and then somebody throws another idea at you, and then another. Pretty soon you’re losing sight of what your main goals are.

You have no idea what the impact will be

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.

This can be especially frustrating when you have a better idea that you think you really should be working on.

A million solutions but none of them fit

So, you probably find yourself turning to Google and the results probably look a bit like this.👇

You're finding a million articles on the problems that you’re having, but none of them seem like they would actually work at your company.

Product advice almost always lacks context

It doesn't describe all the factors that lead to the success of a given method. 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.

I know you don’t have time to sit here and read a novel on shipping. That’s why I’m gonna break the factors down as concisely as possible. Firstly, product is really a system.👇

You can't truthfully separate out one part from the rest. It all plays together, and everything you do influences other parts of the system. This makes it really hard to figure out where to start. But don't worry! The fact is👇

The most important thing is that you don’t get discouraged. Think of it as an ongoing experiment that you can tweak and test and improve along the way. You won’t get it right all at once, but think of it as trial and error. There are many different steps to shipping.

But to save you the time of reading a novel, I'm going to focus on the steps that are the most relevant to shipping things on time and building momentum. The added benefit is that you don't need to change your entire process for them to be useful.

First: a note on hitting dates

Hitting dates relates to 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. Failing to miss those little dates has a domino effect. It’s going to have a big impact on whether you’re able to hit your big deadlines.

There’s a secret to hitting dates

Okay, so it’s actually a not-so-secret process, but the point is it’s effective. You have to avoid thinking about the feature when you're setting the date. Instead, you have to focus on the outcome. Firstly, as with many other things.

You need a story

The story is the problem that you're solving. Your story should be really specific. Let me use Drift as an example. We sell into marketing and sales teams. I could say, for example, the marketer needs to log into X.

But that's not enough. Is it the CMO? Is it the VP of content? Who is the protagonist of your story? The more specific you can get, the greater the likelihood that you’re going to ship the right solution when the time comes.

You need a date

This is how you understand how much the product 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 that they're going to build.

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. Ryan Singer, Head of Strategy at Basecamp, created this really great diagram.

What this diagram shows is that once the team understands your constraints, they spend their time discovering the solution within the context of the story and that date.

If this isn’t the case, you end up with a situation that resembles the right of the diagram, where the scope continues to increase and increase. Pretty soon you end up with all of your smaller deadlines slipping away from you.

Instead, you should give yourself a fixed time and a variable scope. That's how you're gonna hit those dates day in and day out.

An example problem

To 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.

We typically call this a report. It’s perfectly reasonable for a team to want customers to understand a metric. There are many potential filters that have to be considered with this metric: Time, geography, individual differences between customers, and so it is important to be able to customize.

But, equally, you can imagine how your scope has the potential to spread beyond control as you introduce more variables. But you can probably also solve the problem by running an 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. After the SQL query is sent, then you can start building on that. By the time the date comes to pass, you can ship several increasingly better solutions to their problem over time.

It’s not about getting an estimate right

You don’t want to be sitting down with your engineering team, for example, and coming up with estimates.

If you end up picking a date and mandating what your feature should be, you're going to get stuck in that land of story points, sandbagging your estimates and constantly missing your dates. It’s a terrible place to be, and no one wants to be there.

What’s the story?

So, now you have a date, but wait, you still have to figure out what the story is. To put it another way, the story is actually the problem that you're going to want to solve.

At Drift, we use the ‘job-to-be-done’ framework. This boils down to what problems you can solve that will have the largest impact on the mission that you set out to achieve. The mission is typically a goal.

First, talk to your customers

The key to getting a tight job done right is a deep understanding of your customers. Above all else, it's the number one most important place to start.

You have to talk to them, and you have to talk to them live. At Drift, we have a Slackbot that asks us how many user exposures we’ve had each week. I set myself a personal target to never have a zero. A week should never go by without me speaking to a customer.

If you're at a company that doesn't allow you to do that, and you're a product manager, I would honestly quit.

Customer contact is the absolute best way to understand what you should be building. Let me give you an example of something that a real customer sent me when trying to express what they wanted from my product.

This is gold! Imagine being able to go to an executive and say, “Hey, this is exactly what the customers want. This is exactly the problem that they're running into. And here's how we can fix it.”

Talk to the customer team

So, you've talked to the customer, but now it's time to expand that coverage. It might be worthwhile talking to the team that spends their whole day talking to customers, the CSM team.

It’s a really good way to broaden out the knowledge that you're getting. One tactic we have again is Slackbot. It pings our team once a week with a topic that we're curious about and gets their feedback.

It does this instead of just going out one-to-one and asking different people about their interaction with the problem. This allows you to crowdsource that knowledge and then you end up seeing a really rich discussion between those people. This can be really helpful.

Engage as many people as possible

We also just started testing out a board where people can write up customer pain points. We can engage even more people at the company in this discussion. This has really been great for visibility.

It’s a great tactic to help you understand the full scope of a customer problem. If you ever feel like the people that you're talking to are only giving you part of the problem, this is a good way to broaden your understanding of that problem.

Summarize into the JTBD

Once you understand your customers and you know your mission, you can smash it all together and summarize it into a really crisp story that describes the problem that you're solving. Typically, we’re gonna follow a step by step framework.

I believe in taking a lot of editorial liberty in telling a story. 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!

The JTBP is a problem, not a feature.

What's important to remember is that the story should describe the customer problem in really specific detail, including why that problem matters to the customer.

It still does not and should not talk about the solution. You still haven't picked your features, meaning that the scope at this point is still variable.

You're still on your way to hitting your dates. At the end of the day, when you're doing this initial research phase of the job, 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 that the team is headed in the right direction.

Or, worse, they might be shipping something amazing, but it might end up not being as relevant for your business as it should be. If you define your problem really clearly and precisely everything else downstream is going to be easier.

You're going to start with a much deeper shared understanding of what you're trying to accomplish.

Next: Story time

So, let's say you did all this stuff really well. You have your problem, you really know what you want to tackle.

The next step is story time. I think this is something that everyone can try, regardless of the system that you're in. All it comes down to is a meeting. Story time is how you transition from the problem space to the solution space. It's the start of all that great design research that we know and love.

Hold a meeting

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

In the meeting, you should bring in the whole team that's actually going to work on the problem set out by the PM. This should include:

• Go through the problem.
• Go through your research.
• Tell everyone a rich story about the customer.
• You develop open questions that have to be answered.

In the end, it’s probably gonna look a bit like this. 👇

This whiteboard is full of comments like:

• What would it do?
• What's it gonna look like?
• Is this possible?
• What are the different ways we could approach this?

The end result of the meeting

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

And then everyone goes off for hopefully a day or two maximum and comes back and you share what you've learned. What you're doing is engaging the full team and discovering the solution.

It's not like a PM is writing a spec and just handing it over to the engineering team. The engineering team, and everyone else, is involved in the solution.

Refine the scope

In answering open questions, you're trying to figure out exactly what the solution is within the constraints. Once that’s figured out, you’re good to go!

Early access

Now that you're in the process of building, the next step is to make sure it actually is going to meet your customers needs the way you thought it would. We use a tactic called 'early access,' which means picking a small handful of customers to partner with in finishing what you're working on.

Below you’ll find a 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 misses 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.

Selecting the right customers

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

• They should represent the target persona for your business.
• They should be willing to use something that might break.
• They shouldn’t be the kind people who are going to say that everything is great.
• They should be open to speaking publicly about using your product.

Start with the customer team

I always ask for my customer team’s recommendations, it could help with an expansion opportunity. Or, it could just get someone really, really excited and turn them into an evangelist, especially if you're not in the B2B space.

Here's an example of me getting customer feedback from Slack. I’m asking them to rate the product on a scale of one to ten.

We have shared Slack channels with some of our customers to help facilitate this process. You can literally DM a customer and ask them for feedback on the product. Equally, you should be open to them messaging you personally.

Know your customers

No matter how well you think you know your customers, they're always going to surprise you. They're never going to be as straightforward and easy to understand as a persona.

No matter how long you work in products, your customers are always going to keep surprising you. Don't be arrogant, don't assume that you know what your customers need. Just spend the time talking to them, because it's always gonna be worth it.

Make sure your customers like it

You've been talking to your gap customers, and you've been iterating based on their feedback.

The last thing that you need to do before you can move on and launch publicly, is to not only make sure that you've solved for that job to be done, but to make sure that your customers like it.

This attitude is how you know that you're starting to hit the mark with what you're doing. You know that you're building something that's going to be exciting enough to drive your business forward.

Ship it!

So, you've hit all your dates, everyone's super excited, and you're getting 10 out of 10 in your feedback.  Now it's time to launch publicly. This is where that product-led magic really starts to click into place.

This whole time you've been super-focused on your customers. You've done all that research and you're successfully partnered with your customers. This means when it's time to launch, you already have all these stories, you already have case studies and you 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. And, 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. Every single one of them can articulate who it's for and why it matters.

When we launched Drift Automation, the materials that we used were all about the person that we were building for and the problem that they were experiencing.

None of this was about the technology that we are 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

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 watch publicly, but then limit the release.

If you've done a good job and you really understand the problem that you're solving, it's going to be relevant for those customers.

And then all of a sudden, you're flipping the script on them. You get a situation like what you see above 👆. These are all examples from enterprise customers saying we actually do want to participate in this.

This is because you’ve built anticipation by limiting the release. Also, your customers aren’t as overwhelmed by a big change all happening all at once. At this point, you become the hero, because you’re the one shipping the thing.

Three questions to wrap up

Maybe the most crucial of all of these is, are you making your customers happy? If not, what can you do to change that? Whatever happens, don't forget to evaluate and use what you’ve learned 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.