How to Fail Fast: Building the New Without Destroying the Old
This post is Part 3 in a series. Read Part 1, Part 2.
You’ve got questions, answers, metrics. You’ve picked the changes you’re going to make and defined how you will evaluate their success. Your product management organization is excited and you’ve got executive buy-in for moving full speed ahead.
But wait – no one likes change. The other teams in your company are going to have objections. Existing users are going to complain. You’ll be tempted to refine your vision under the radar for awhile, but that’s a recipe for failure.
Your job as a fast-failing product manager is to frontload the “no’s”.
Here’s how you start:
Internally, Bring Everyone in on the Story
After you’ve been planning this product strategy shift for weeks, it may feel like it’s “old news” throughout your company. It’s not.
The majority of the cross-functional teams have no idea that what they’ve been working so hard on is not putting the company on the path to success. If you don’t share the “big picture” with them, your changes will seem arbitrary and disconnected. Most people won’t actively try to sabotage your plans, but working with teams who feel undervalued or excluded will still doom your product, albeit more slowly.
You don’t need (or want) a long PowerPoint presentation. Here’s what you need to cover:
- Here’s what we set out to do (Build X and sell it to people)
- This is what we built and what’s good about it (X is a great product that does these things and has thousands of happy users)
- Here’s why this isn’t enough to make the company successful (Thousands of happy users isn’t enough, even if they paid us 5x as much. We need millions of users.)
- Here’s what we’re doing to do next (If we build Y and Z and change our sales strategy in this way, we will be able to attract millions of users.)
- We’re still working on the “how” (I will be meeting with teams individually to get your feedback, answer questions, and get you to challenge the assumptions I’m making)
(Some similar thoughts on another blog, from a testing perspective: How to Get Traction in Your Team)
Externally, Invite Customers to Be Part of Change
Even if your customers can’t see any changes to your product or website, they are likely to sense that something’s going on. Maybe bugs that used to be fixed overnight are lingering a bit longer, or maybe they notice that the “feel” of your marketing newsletters has changed.
It doesn’t matter why. What does matter is that they’re likely to stop recommending you to friends, log in less frequently, or surmise on their blogs that you’re going under.
You can easily avoid this by giving customers a heads-up that some things will be changing, that you’ll keep them informed, and that you will be asking for feedback.
In my experience, even a customer who disagrees vehemently with every change you make can be retained as a customer if they feel that you have kept them informed and given them the chance to preview what’s coming.
You’ll need a little bit of prep work before you go public:
- Figure out how much feedback you can realistically respond to. For example, if you have 10,000 active users and 1% take the time to send you a freeform email, that’s 100 emails – a manageable number to read and respond to. If you have 10,000,000 users, you can’t possibly read 100,000 emails or messageboard posts – so you’ll need to ask for feedback in a more structured manner such as surveys or polls or risk looking unresponsive.
- Create an announcement-only mailing list that customers can subscribe to. This is not for general-purpose discussion – it’s a one-way list for you to announce updates, solicit participants for usability testing, send out surveys.
- Draft your “things are changing” message and test it out on 2-3 hand-picked customers. Make sure it addresses their concerns (“will my data go away?”, “if I have to start paying, how much warning will I have?”, etc.) and adjust as needed.
- Create a new home for the new product changes. Set up a dedicated, separate URL for announcements and later, mockups, prototypes, and the beta. This gives you the freedom to “play by different rules” – restricting access or providing more access, setting up test databases or just having more downtime.
Validate as early and often as possible
It’s probably not a good idea to post your entire roadmap and requirements online, but that doesn’t mean you shouldn’t get feedback from the very earliest stages. Use that contact information you have to invite a small sample of users to preview your earliest mockups. The most secure method is to physically bring them to your offices and show them hard-copy sketches, but the easiest way is to send them a URL to look at, give them a call, and ask some questions.
This doesn’t have to take more than 30 minutes per person – and even listening to just 2 people can provide a valuable external perspective. Every product manager has an hour to invest in validating their product.
What I did at Yodlee, which worked incredibly well, was to put together a click-through demo of how we envisioned the new product, and present it via webinar to a group of existing users. It gave them something visual to react to, which resulted in them asking excellent, challenging questions. As that click-through demo was refined, I turned it into a Flash movie that we shared with more and more users.
And remember – it’s not just users! Many product managers are hesitant to share their early prototypes with sales or customers, for fear they’ll be committed to rushing something up the roadmap. But it’s an invaluable source of feedback (remember, you’re front-loading the “no’s”).
So don’t hand off your prototypes to sales – volunteer yourself to give presentations to a few key customers. Since you’re a product manager, you can set the tone as “you’re a valuable partner to us” vs. “here’s what we want to sell you”. I’ve learned about a lot of potential dealbreaker/dealmaker features early by doing this.
Plan for transition
I cannot stress enough how important this is. There are lots of questions – internally, start asking them now.
- What are the deltas between the user experience now and what they’ll experience with the new product?
- Are there reductions in functionality?
- Does data need to be migrated?
- Are there customizations to the old product that may not translate seamlessly to the new one?
- Will new features require additional bandwidth/processing power/database hits?
- If you’re providing a SaaS or B2B2C product, how will the upgrade affect the customer in the middle?
The mistake many product managers make is thinking, build the product first, then we’ll worry about upgrades. Wrong! If you don’t think about upgrades, you may never get to show off that awesome product you built. For enterprise customers, the upgrade is the product. Treat it as such.
This post is Part 3 in a series. Read Part 1, Part 2. (Stay tuned for Part 4 next week!)
