tldr: When the problem you set out to solve has changed, first focus on getting the internal communication right to your own team, before investors, customers or anyone else. That’s the first step towards your pivot.
—
“Why is our customer clicking on these links that lead to other what they most recently said on twitter instead of their contact info?”.
“I thought you said the primary difference was that the heart of our system was the individual, not the social media post?”
“We just moved from a tab based UI to tiles and you want us to move again to a news feed UI? Do we even know what the customer wants?”
All these were the questions that I got within the first 4 minutes of talking to my team about changing our product direction (it was not fashionable to call it a pivot at that time).
We were cruising towards alpha in Sep after a few glitches when I scheduled a call with 5 of our early customers, most of whom were on the East coast. The call and demo was scheduled at 7 pm IST and about 930 am Eastern. I was going to go over the demo with Paul Dunay, who at that time was at Bearing Point. Paul was one of our early champions and a very astute guy who understood what we were trying to build. I was at the office with my CTO and friend Giridhar who was listening intently to what Paul had to say about the product. It was as much his sweat and tears as mine so he was hanging on every word. It took us about 3 minutes to finish the demo. The product was in its alpha so there wasn’t much to show I thought. After what seemed like a really long pause, Paul said “Well its good to see the progress guys, but I think you’re a little ways off from when we can use it for Bearing Point”.
That set off a series of questions to understand why we missed the mark. Even before the days MVP (Minimum viable product) was a sexy term, we thought that’s what we had. Turns out the problem that we were initially thinking we had to solve had changed.
Dramatically.
In less than 3 months.
The new problem required a solution that had to first have us change our data model, our user interface (new wireframes, too) and finally required access to data sources which we had not planned on acquiring. So basically a “total rewrite” as Giridhar put it.
Problems change. The perception of the problem changes. The customer’s needs change. When you are on the cutting edge of an unsolved problem you ought to expect that.
So what did we do?
We had to get buy-in first from our engineering team. There’s one way that worked and 3 ways that did not work.
The things that I tried that did not work:
1. Showed them a few competitors applications and told them about what the new problem is – big fail. Most engineers I worked with really did not care much about the competition. They were convinced no one was solving the problem the way we defined it.
2. Put together a wireframe, complete user interaction scenarios and use case description. Interesting, but they were not convinced we had the “new” problem nailed, since they felt we were grasping the last available straw.
3. Took them all out to lunch to detail why all the 5 beta customers were logging in, clicking on all the “wrong links” and then logging out within 50-58 seconds.They felt the customers still did not know where to click.
What worked:
We scheduled a call with our beta customers – Ross Mayfield, Paul Dunay, Mike Prosceno and did a remote record as each user went through the application one screen at a time. We made sure all of our 3 engineers were both on the call and also looked at the entire 9-10 min video recording of each customer’s interaction with our application.
Its an old adage – “Seeing is believing”.
When you have your engineers hear and see customers struggling and clicking on the wrong part of the application looking to find what they were hoping to, they get religion.
