(This is a great case-study on the “big middle” by Garrett Moon, TodayMade.
I often talk about how most customer learning happens at the tail-ends of the product development cycle – while you’re gathering requirements and after you release your product.
There is a “big middle” where the temptation is high for spending several weeks, months, years building and perfecting the solution. This is often where we also go astray and either build too much or build the wrong product.
The key is building a continuous feedback loop with customers throughout the product development cycle.
It isn’t exactly known for its high-tech startup vibe, but it is the place that we call home. We love it, and it really isn’t such a bad place to run a startup. Sure, the winters are cold, but the economy is booming and the workers are hard working.
This is the story of TodayLaunch, a product that started with a simple idea and a hypothesis, and learned a lot of lessons along the way.
In 2010, my business parter Justin and I were fresh on the startup scene. With two months of client business under our belt and the launch of our first “web app“, we discovered a new problem that we thought we could solve. That problem? Social media management was hard.
While there were admittedly plenty of tools available, the process of learning how to use them effectively (for business) was complicated. We tried many of the typical software solutions that were available, but our clients rarely succeeded with these tools. Most of the time, they became even more frustrated than ever.
The problem with those tools was that while they technically allowed users to complete social media tasks, they were messy and did little to help make customers actually better at social media marketing. Business owners are busy, and we found that the failure rate with those products, like HootSuite, was high.
We knew there had to be a better way, and so we began with a basic hypothesis: Business owners needed to do three things in order to succeed. From that hypothesis, we developed three tasks.
- Respond – Users need a single to-do list encouraging them to respond to all incoming messages.
- Connect – A tool to monitor outside conversation happening about their brand.
- Learn – A place to “follow” outside sources (RSS feeds) that could be shared with their brand.
Our solution was simple: Create a three-tabbed interface that allowed them to do those three things. Our proof of concept was done by the end of the next day. Our minimum viable product (MVP) was done in two weeks. Within three weeks we hit the road to sell our sorta-working product.
A Hypothesis, a Large Coffee, and a Full Tank of Gas
We laugh now about how little coding was done when we made our first sales call, but boy did we learn a lot in a short time. With our product at a reasonable MVP state we contacted approximately 10 local businesses to setup demo meetings. We were able to put together about six great meetings with a variety of local businesses and organizations. Overall, there was great interest in the product, and we sold one copy that day. There were a few holes in our plan, though, and here are a few of the things we learned:
- Customers wanted simplicity. We were correct in that users found the current solutions too complex, and that they were willing to explore new platforms.
- It wasn’t their workflow. While users understood our three tasks, those tasks didn’t really resemble their current workflow. They didn’t fit.
- Monitoring, not so much. Monitoring was less important that we had realized. There wasn’t sufficient data for most businesses to monitor.
- Yes to the inbox. The inbox comparison resonated with people. They liked the idea of “archiving” certain messages like email, but our product didn’t look or feel like an email inbox.
- Adopters, not establishment. Our meetings weren’t with the right kind of people. They were looking for ‘establishment’ products and weren’t willing to gamble on a startup. We needed to find some early adopters.
Once we got home, we finished the product. The fist users (one paid, and a few free) received their access within two weeks. It doesn’t get more MVP than that. The product they received was woefully under-built and desperately flawed, but they feedback was positive in the right way, or at least positive enough to continue forward.
The Second Iteration
In a matter of a few weeks, we were ready to iterate. We based our second iteration on a few new assumptions and ideas.
- Familiarity is not contemptible. We needed to look a bit more like the “other guys” and better resemble an email inbox.
- Simple and clear names. Our naming conventions for key “tasks” were convoluted. They had to change.
- Teach the tool. We needed to better convey what users needed to do in order to be successful at social media. We needed to figure out how to teach them while they worked.
A New Interface
The new interface design did a lot to fix the initial problems with the application. We incorporated an email-like feel and new naming conventions. We also added a few giant buttons to help convey the idea of completing or ignoring each message – sort of like a to-do list. This version was a big improvement on the first version, but it still had many flaws.
Our Start In Training
One of the major ways that we began learning about our customers in those days was through a newly developed training program. We created a three-hour social media training course that taught methods that were easily executed using our software. We began offering live-training events to our local market. The training was a great learning experience for our clients, but even more so for us. We began to understand our users’ mindset and needs, and definitely learned about how difficult it can be to host live events.
A Few Lessons Learned
Like clockwork, our second major iteration was a bit hit in the learning department. We picked up a few more users (which wasn’t too easy since they were still being manually added to the system). Some of them actually used it, others didn’t. A few took the effort to send us feedback. We became somewhat discouraged, but stayed committed. We filled the silence with some new assumptions and way too many guesses. We didn’t have a lot to lose.
Our guessing eventually lead to the release of a “fully-baked” version and our first pay-wall. The product was not a success. We had several hundred signups, but only a few organic sales. In the end, there were only a few regular users, and we were most of them.
A Troubled Back-end
One of the things that we learned at this stage was that we needed to look into a complete rewrite of the software. That was heart-wrenching, but the technology used in our MVP was not cut out for the work that we were asking it to do. We needed a modern education in app development. Our interface had also become far too complex for the templating system. If we wanted to do this, we needed to do it another way.
The Year of “Speed”
It would be a full year before we made another significant launch of our product. We shied away from selling the current version because we were worried about how it would perform. In reality, this was not a very good decision. We left our build, measure, learn roots. While the rewrite was necessary, we stopped learning, and started guessing. We also hit a productivity rut.
During this time we probably started and stopped three or four new versions of the product. There were difficult conversations, and a few unreasonable accusations about each other’s “commitment to the product.” We felt stuck, and were making big guesses. While we had a few users, we weren’t finding ways to get good feedback. Asking doesn’t always work.
I remember feeling like we had an idea and that we were onto something, but we also felt like we had no hope. It was at this time that we learned the importance of small batches. When we went in for the re-write we chose to build a completely new product to the level of the first, rather than another MVP. This was a mistake. We got buried, and we lost momentum. I am convinced that if we had kept it small we would have launched sooner.
By the time we realized our mistake, we decided that it would be easier to drive through the mud rather than go backwards. In the end, I am not sure that this was the correct decision either. We were bootstrapping our business by doing client projects, so it became really easy for that work to occupy all of our time. TodayLaunch was sort of forgotten, and became a sore subject around the office.
These are the early and dark days of our product. They are frustrating to think about, but served as a valuable lesson.
Something changed in the spring of 2012.
After growing our client business to a level that could sustain us, we came up with a new plan. As early founders, it felt like we had to let our product go dark in order to shed a few stronghold assumptions. We developed a new name, and a new theory on how everything would work. We cut a bunch of dead weight, and adopted the Twitter Bootstrap framework so we could build faster. TodayLaunch had new wind in its sails.
It was at this time that we killed our first pay model. The first iteration was too expensive, and wasn’t working. We needed to change our focus from revenue to learning. We released a new product on new technology with half of the features in a matter of a couple of weeks. We called it beta, and made it our new MVP.
Build. Measure. Intent.
The one major mistake that we made early on with the new release was in how we approached testing. We hadn’t yet become good at testing key assumptions and theories. We were releasing large-batches and not testing them in an effective way. We were also working heavily off of our own best guesses because we weren’t gathering regular user feedback. It wasn’t that we didn’t want the feedback; we just didn’t know how to get it.
Finding Our Feedback
We were dealing with a big misconception that surrounded how we were collecting user feedback. Using Intercom, we were constantly asking our users what they thought about the product. Unfortunately most of them didn’t have a lot to say. They didn’t know what they wanted, and we were asking the wrong questions. We weren’t using a scientific method for learning. We had the data, but weren’t putting it to good use. We finally did three things that helped us get past this problem.
1. We used the data we already had. Our database held important information about all of our users. Once we started digging, we were able to understand how many social accounts each user had, and how many of them were using our product the way we intended. We learned a lot, very quickly.
- Business owners did not take the time to learn or implement a social media strategy. They were just trying to survive on their Blackberry!
- Users weren’t using any of our monitoring tools effectively. The interface was still confusing, and it wasn’t clear what they needed to do with the data.
- They liked the product. We were gaining passionate users that relied on what we were offering.
- Our new features were resonating well. Our users wanted a better inbox and awesome publishing. Our worries about monitoring were un-founded. This was not a major reason that our users used the app. We needed to invest our time into alternate areas.
2. We conducted a real survey. Believe it or not, but we had never really conducted a survey of our users. I am glad we didn’t, because we would have asked all the wrong questions. We accidentally stumbled on a free tool by KISSmetrics called Survey.io that we shared with our users. We learned at lot.
- We learned, again, that our users really liked our product. Almost 90% of our users said they would be “disappointed” if we went away.
- They were getting our concept. The liked the single inbox interface, and appreciated our clean simplicity. TodayLaunch helped them get more done more often. It was working!
- We learned that 100%, yes 100%, of our users would use HootSuite instead of TodayLaunch if we went out of business.
As much as we tried to pretend that we weren’t in competition with HootSuite, our users thought we were. This was a huge revelation, particularly with our marketing message. We were being compared to HootSuite no matter what, so we might as well own it. And, own it we did.
3. We gathered feedback from our competitors. Now it just feels stupid. Up until this point we hadn’t done enough to consider what our competitors were doing. For so long, we believed that a scrappy startup couldn’t compete with a VC funded powerhouse like HootSuite so we shut our eyes and focused on our local market. In reality, we did’t need to. HootSuite will always be HootSuite. We had tapped into a group of people that were choosing to not use the biggest name in the business. They had good reasons for doing so, and we could capitalize on that. Even venture-backed businesses have weaknesses.
We spent an entire week researching the most common complaints against our competitors. The great thing about doing business in 2012 is that this kind of information is freely available – everywhere! Our Basecamp project is literally busting at the seams with ideas and features that will clearly set us apart against a formidable competitor. Here are a few things we learned.
- We already had key features that our competitors users were asking for, but they weren’t the features that we were talking about in our marketing. We had taken for granted that things that made us the most different.
- HootSuite has a lot of fans, but there are plenty of people that wanted something different. We could, and already were, building a movement around that.
- We couldn’t out-develop a venture-backed company — they had a huge running start — but we could develop smarter. By focusing on small batches and a few key features, we could create inroads with new users.
A New Product, With A New Outlook
Getting TodayLaunch to the point it’s at today took us two years, but once we started learning like crazy, it only took us four weeks to launch a brand new version with an outlook for success. After launching our second MVP, we launched small-batches on a monthly basis until announcing our pay-wall 6 months later.
Now, we are lighter, faster, and smarter on our feet than ever before. In our first life, we believed in learning, but we didn’t know how to get it done. We were also too focused on large releases that bogged us down. Once we re-focused on learning and a few creative ways for doing so, our product exploded. We had more signups in the first day than the entire previous month. We made our first real sale in the new life of the product almost instantaneously.
For the future, TodayLaunch is committed to learning. We’ve embraced KISSmetrics and are committed to releasing in small batches. We know that we have an unlimited number of lessons yet to learn, but the future looks brighter than ever before. All because we decided to focus on learning before and while we build.