Using duct tape and baling twine, you can build almost anything you need. It won’t be pretty, and it’s a good metaphor for finding a way to create a solution for an unknown problem. The first step is to do whatever it takes to find a workable solution. The next step is to see how well your improvised solution works. And finally, if the problem still exists and your solution is directionally right, you’ll need to find a more scalable way to solve the problem.
Finding a workable solution may mean using a kind of hack. Start by imagining how the process should work if there were no impediments. Recently, I wanted items from a calendar to show up on an Agile board – the goal was to understand how many of each item showed up in each list. A perfect solution would be an automatic import from the calendar. An imperfect solution would be to copy each item manually from the calendar to the Agile board. The end goal is the same – understand which calendar items belong in each buckets.
Go for the “It’s Done” Solution
My duct tape and baling twine method in this case? A product called Zapier – a kind of “data glue” that allows you to connect events in one service to events and data in another. I started by connecting Zapier to the Google Calendar and I also authenticated against Trello, a simple solution to create Agile boards. Zapier connects products using recipes for events triggered by data in a service. My recipe matched data in the calendar events to particular buckets in the Trello board. Using the date/time of the event and translating it into the day of the week didn’t work, so I had to use a different method: adding characters to the description of the calendar to indicate a particular day (a manual solution FTW).
Did the temporary solution work? Absolutely. Events added to the calendar now show up on the Trello board, which is a big improvemen over the previous method. To get the results into Excel, I also added another bit of duct tape – a Chrome extension to export the Trello board items. As an end-to-end solution, it works. As an automated process, it leaves a bit to be desired.
Next Steps: Building a Feature
So where will this solution go next? It needs to scale to be usable. Events need to get added to the calendar automatically and coded in such a way so that they show up in the Agile board. They also need to show up in the right place. The feature version of this idea could be feasible if there are additional user stories, a documented process showing how these events “live” from start to completion, and some idea of when the manual process will break. Start with duct tape and baling twine and build a “fake it until you make it” version. Then, test that version and see where it breaks. Finally, compile the “must have” and “nice to have” items and pick the best ones.
When you write out an idea it’s tempting to include everything. First, the part of the idea that was nifty; then the part of the idea that explained what you meant; and finally the words that convey the essence of the idea.
When you say that idea out loud to someone who’s never heard it before, you realize instantly whether that idea is any good. And you probably notice that you need to take out a lot of words before your pitch sounds more like how people talk.
Pitching is an art. When you’re at an event or a trade show, you get the opportunity to practice that pitch lots of times. The problem is that you can get comfortable with a pitch whether or not it’s a good one.
The best pitches sound natural – they are succinct statements of value that use the fewest words possible. They don’t sound forced, and they solve a problem for the customer.
Effective pitches are also transactional – you are trading value for attention so you had better be valuable. Here are a few things I’ve learned lately while sharing ideas:
1) be brief. What can you say in the first 10-15 seconds that will encourage the person to learn more?
2) be respectful – remember that you are often interrupting someone when you pitch. Even if they are in the mode of receiving and evaluating information, why should they care?
3) give to get – finally, offer something of value and be specific about what your delivering. Are you saving the customer time, money, or something else?
This essay is written as part of the Startup Edition project – check out the other essays here.
It would be awesome if your first iteration of a minimum viable product (MVP) perfectly addressed your target market segment, delivered great value to your customers, and you never had to change it again. However, that’s not what happens. Your first MVP iteration is the beginning of a build-measure-change cycle. When done right, you’ll deliver the product your customer wants to use for the job they want to get done. So how do you figure out how to find that customer, understand what they want, and deliver that product to them faster?
Finding your customer is the first task to making your MVP less wrong. If you’re baking cupcakes, who buys them? If you’re making software, what is the general profile of the person who should need what you’re offering. And what problem are you solving for that customer? A good problem statement for baked goods might be: “I’m delivering a donut for an underserved market that has specific allergy needs for people who like breakfast snacks once a week.”
Now that you’ve made a statement that matches what you think your customer might want, you should ask them what they want. This action can take many forms, from informal surveying of friends to more formal methods like online surveys, usability studies and tests. You need to be able to answer the question: what does your customer want? You might find they want different things than you think that target customer wants. So ask the question “do you ever eat donuts?” And also the question “what sort of donuts would you like to eat?”
You can uncover a more nuanced version of this question by asking what your customer needs. Often this need displays as a pain or discomfort that the customer wants to avoid. For our baked good example, a customer allergic to nuts might have very strong physical symptoms when eating a product with nuts – in fact, the decision could be life-threatening to some. Consider how strong that statement is: what does your customer need? Customers will display needs differently than wants, so make sure you watch what they actually do in a given situation rather than just asking them how they feel. Then, after you observe the need in action, ask them how they would feel when that feature/attribute/product is taken away. (Would they pay to keep it?)
If you can find a customer, ask them what they want, and uncover some of their needs, congratulations! You’re well on your way to developing your plan for an MVP. So why can you deliver this benefit better than anyone else? A suggestion: you won’t be able to deliver every benefit better than anyone else in the world. So focus on a small (a really small) thing that you can do better than anyone. And soon you’ll understand whether you picked the right small thing to focus on and whether your customer cares that you’re solving their problem.
You should also ask yourself – why is right now the time to deliver your solution? Try to answer the question: what’s the trigger for my customer to buy to relieve their pain by using my product? If you can deliver that benefit at the right time for the right customer better than anyone else, you’re getting closer. And if you have managed to avoid “boiling the ocean” by focusing on a small thing that you can measure, test, and learn from you’ll have an even better chance of making your MVP less wrong. At some point you also need to know whether the combination of the customer’s pain and the solution matches the set of things you can do at a reasonable cost.
How can you make your MVP better? Make sure you ask valuable questions of your prospective customers. Acknowledge their needs and their wants and respond by demonstrating that you’ve heard their needs and delivered something you believe addresses those needs. And build with the idea in mind that you will measure specific outcomes, learn from the actual behavior of your customers, and then change the MVP to make new experiments that get you closer to being less wrong, quickly.
This essay is written as part of the Startup Edition project – check out the other essays here.
“Do not fear mistakes. There are none.” -Miles Davis.
We all make mistakes.
I’ve made a few mistakes in my time. I’m not talking about the garden-variety mistakes you might make in the course of the day. I’m talking about product development whoppers, or the kind you look back on several years later and wonder, “What was I thinking!?”
You make the best decision you can based on the information you know at the time and your framework for making decisions. There are a few decisions I wish I could take back, because if I could change them now, they would be great companies (or at least, I could feel like I made the right decision 10 years later). They were ideas for products that I still want now, that still solve a concrete problem, and that people are still willing to pay money to solve. (These ideas also work because they enable the businesses that use them to make more money and get more yield out of their current investment.)
What was my biggest mistake?
My Biggest Mistake was not trusting myself to make the right decision with the information I knew at the time. I didn’t have all of the answers – how to execute, how to find the money, how to deal with the ups and downs of being an entrepreneur – and I let that feeling of being out of my comfort zone make my decision for me. The lesson for next time? Be comfortable with being uncomfortable. Trust my gut more, and be in the moment when struck by a big idea that wants to be real.
Now, you decide whether I should have gone forward.
Here are the ideas that I had and decided not to do. Read them with the knowledge that you have in 2013, and decide whether you would pursue them today: I would.
Big Idea: Make the Grocery Store Easier.
Idea #1: Imagine if the next time you went into your local grocery store, there was a way for your phone to tell you the location of every product in the store, to remember your past preferences for shopping, and even to direct you in an optimal aisle-by-aisle route to minimize the time in store? And what if you received loyalty rewards and marketing offers that pertained to you? And what if you could check out of the store simply by scanning each item with your phone as you placed into the cart. That idea sounds promising and real in 2013, and quite similar to the idea my friends are pursuing at qThru.
When I thought of a very similar idea in 1999, even though the hardware and software was off the shelf and readily available, I didn’t go and build it. I made the decision that “I wasn’t the type to do that,” and “I’m not an idea guy” and let self-doubt make my decision for me. I can’t have that decision back, and I know that what I was really feeling in the moment was, “oh crap. I have no idea how to even begin thinking about that much less how to build and monetize it.” And, it happened again.
Big Idea #2: Make Waiting at a Restaurant Better.
Idea #2: Imagine you arrive at a popular restaurant. Because they are very busy, they ask you for your phone number so that they can text message you when your table is available. At the same time, they ask you to join their loyalty program so that you can participate in drink specials, learn about special events, and play games or trivia while you are waiting in line. It exists today – it’s called TurnStar – and I’ve used it. It’s pretty slick.
Why didn’t I build my version? It was called TextMyTable, and I was ready to go with the vision, the business plan, and the execution play. It was September 2008. Then all of a sudden the economy did a flip-flop and all of our assumptions about what was a normal business turned on their head. Or did they? I was stuck because I didn’t know how to raise the money to start the business or to grow the business in such a way that it generated operating capital.
What’s the Commonality?
In both of these ideas (and in others it’s not important to share here), I had an idea for a product or a service that was innovative. The ideas capitalized on a consumer need, solved an actual problem and had a reasonable chance at being successful. We could argue about the size of the market and the relative degree of success, and the fact remains that they were good ideas. And I made a mistake in not pursuing them.
What did I learn and what would I do next time?
The first thing I learned is that you can’t find out whether you’ll succeed with an idea until you try it. (Duh.) The ideas I think that would have been successful might have been abject failures, wild successes, or more likely somewhere in between. And I don’t know because I didn’t try them.
The second thing I learned from these mistakes is that collaboration is everything. I needed to do more to ask people to tear apart the idea instead of trying to build the whole business from start to finish inside my head. Groups like Startup Edition are a great place to get feedback, learn from other perspectives, and to reframe your questions.
And finally, I learned from my mistakes that it’s impossible to know what you don’t know until you do it. (Sounds like a Zen koan, doesn’t it.) What can you do about that? Admit that you’re going to make mistakes. Try to make different ones the next time you approach a problem, and learn from the results. Trust your gut.
We could talk all day about the tools we use. Agile is Best! Pomodoro is Best! Pen and Paper is Best! Getting everyone in a room is Best! (You get the idea.) Because everything in a startup changes ALL THE TIME, it’s also important to consider the conceptual tools you should be using in your startup.
You might pronounce them as Empathy, Resilience, Learning, and Persistence. Doubtless there are other conceptual tools that people find useful and beneficial, but these are the ones I use most often.
What should you reinforce?
Empathy means understanding what it feels like when you are a customer. It also means literally walking a mile in the customer’s shoes. If you are not shaking your fist at the screen when your code does something stupid that customers experience every day, you are not modeling empathy. To get more empathy, stop being a smarty-pants startup person, and think more like a customer. (And get out of the building.)
Resilience is the ability to rebound when bad stuff happens. Because startups do not act according to Standard Operating Procedure. If you are resilient you’ll be better able to pick new paths, to take care of yourself and your teammates, and to invent new ways of solving problems in the course of doing business. You also won’t really know that you’re being resilient until you look back and see the obstacles you’ve overcome. So trust in yourself, do the right thing for you and for your teammates and the people you care about, and you’ll get more resilient. You can always have more work and money. You cannot have more time with the people you care about and you cannot get your bad decisions back. Embrace sunk costs and don’t let them become an anchor that prevents change.
Learning is the most important tool you can use in a startup and generally in life. Learning ensures that you can test ideas and decide when they are wrong and when they are right. Learning also gives you the ability to adapt to a new environment and add new skills. And learning changes you without you even realizing it. So you should keep on learning everywhere. I keep a stack of books on my bedside table and read one or two books per week.
Persistence is the glue that allows you to respond when you are not feeling empathetic, when you are not very resilient, and when you feel that the learning you should be doing is stalled. Persistence is getting up in the morning and understanding the 20% of the work that you absolutely must do that will deliver 80% of the reward. When you are persistent, you are doing the hard practice that makes many other things possible. And when you can’t be persistent (this happens too) you should embrace the sunk cost and go outside. Meet people. Exercise. And above all, embrace the Cult of Done. Perfect is the enemy of Done.
Why Focus on Portable Tools?
Why are these the tools that I use in a startup? I use these tools because they are portable, I can share them with other people, and they are additive. There are many tools and services that people could be using in their startups, and they are all dependent upon the people in these startups to use them well. Start with the tools that reinforce empathy, resilience, learning, and persistence and your startup will prosper.
If you’re reading this post, it’s likely someone took a chance on you. If you got a “lucky break” somewhere along the way, someone took a chance on you. And if good things tend to happen when you’re around, I’ll bet they often started when someone took a chance on you. You have to be good, and lucky – this part is about the lucky. Continue reading →
Why you should bring your interactions to the place where people already spend their time.
Email is the #1 Destination
Ryan Hoover published a great article the other day on the trend of using email as an interface to do other things. You probably already use it in this way by sending commands to other systems: “forward this email to my expense site”, “watch my email for interesting stuff,” and “make a to-do list out of my emails.” In my experience, managing tasks through email (though hopefully not using your inbox) increases productivity and makes you generally better at getting stuff done. And there’s a bit more that we ought to be doing.
The “stuff we ought to be doing” varies, and usually relates to long-running recurrent tasks (remember someone’s birthday, maintain a daily or weekly status), project-based tasks with a deadline (I need to get some stuff done before next Wednesday), and one-time actions (“Can you find this for me, right now?”) Email is really lousy at these things, which is why we use other applications for help.
We need a better way to surface applications and services in email without breaking the way people handle email today.
Remember. All. the. Logins.
Awesome! You remembered all of your passwords (or have a great SaaS app to handle that.)
There are so many great applications that are out there (many are even free) that can get stuff done. Now, which ones should we hire to do the job? And what job are we actually doing? Just managing the logins can be a chore, and getting beyond that to switch contexts every time you want to start something new can waste a lot more of your time.
Getting started isn’t easy.
One of the great challenges of Software as a Service products is that there is a login to remember, a site to visit, and tasks to do in that other system that will help you to better manage the minute details of the things you do. You might use Sprintly for Agile Dev, Desk.com for Customer Service Interactions, Expensify for Expenses, and so on. Yet all of these products depend upon you start an action in email and then resume it in another system.
So which app was I using to do that?
When you make constant decisions that force you to have another login, another app to pay attention to when you’re on the go, and yet another slew of notifications, you dilute your ability to make quick decisions. It’s a mental burden to understand which things really need attention and which notifications arrive as a result of long-forgotten decisions that are no longer important.
Ok, Now What?
When you build an application – and need customers to participate – it’s your job to find the place and interface where they will get the most value out of your idea. I believe you should not only make your service responsive but also your service design responsive.
Towards a Responsive Service Design
Making a basic responsive design is pretty straightforward – making an insanely great one is really hard. I think the same is true when you invent a responsive service design. Making your service design responsive anticipates that customers will use different modalities and interfaces to access your idea, and that some customers will never cross into another way to use your idea. App customers may not behave the same as email customers, and vice-verse. But there are a ton of people using email, so how can you add value to their experience without being overwhelming?
Service Design as a concept implies that there are activities that customers take to get tasks done. Completing the tasks may require external actions and may depend on other tasks or actors. Finally, the activity you are designing may happen in multiple places.
Email to the Rescue: The Lowest Common Denominator
Because people spend lots of time in email and there are already many ways to access it, email is a great candidate to act as an operating system where customers might do these service tasks as part of an overall service design.
There are three basic ways you can push email towards being an operating system of sorts:
Create a browser extension – force your way into the experience, either passively (Klout in adding scores to your Twitter pages) or actively (Rapportive, adding persistent information to the existing real estate)
Invisibly solve a problem – have a background service that listens to email and makes decisions or surfaces information based on your preferences (Sanebox, for example, which automatically files your messages)
Take explicit email commands – “add note”, “send tweet”, etc and make them easier to use for “normal” people and abstract them to other media
Time to fight the blank page
All of these methods have advantages and challenges – let’s take a look.
Make a Plug-In
You could make a browser extension that will either take over the real estate or silently monitor or insert information in the places you’ll most likely interact with other services. Plug-ins are awesome for absolute control and transfer very poorly to other interfaces.
As an example, I love Rapportive because it does a great job of using the mostly empty screen real estate I used to see in Gmail and fills it with valuable information about the person who is contacting me. It even shows me the latest view that other people using the same service have of me. Rapportive is a great experience because it exposes some methods to other application services I use (send invitation, start tweet, read Facebook post) without cluttering my view. Some drawbacks of this method are that I don’t have any more mental space for more plug-ins. I’m sure that was one of the reasons LinkedIn purchased this scrappy team.
Create an Invisible Service That Does Your Work
Another way of approaching this problem is to work behind the scenes and make the changes necessary to increase productivity or other goals. This method is cool because it’s client-independent. And it still requires developers to create different interfaces in different client. (There’s less to customize, though.)
Sanebox just works – it filters the email I receive into Gmail labels and then gives me a single digest a day to take actions. From my daily email digest I can delete unwanted messages, set reminders, and see how I’m doing relative to prior days or weeks. When I want to ignore Sanebox, it’s still doing work for me and allows me to close email for long periods of time and then solve for a burst of emails all at once. I don’t have to worry about filing any more – I just search.
Another version of this implementation is the inverse of a service that is implemented everywhere – Mailbox lives only in an iPhone app and allows you to connect to many email clients and apply the same simple management effort to each one. Mailbox takes the best metaphors from the mobile interface and applies them to email: swipe to promote an email to a task or to archive or delete it.
Make external tasks possible in Email
The traditional, geeky way to make external tasks possible in email is to require the customer to send an explicit email command in a subject line or in an interaction body so that the server on the other end of the “conversation” knows exactly what task to execute. In practice, this works well for “send my stuff to you and have you process it” and is harder to execute for “do only the thing I want you to do and not that other thing based on the thing I type.” Normal people – that is, people who don’t talk to computers all day – have a hard time doing this.
Yet the potential exists – many of us use Siri, Google Voice Commands, or interfaces like Google Glass to create a graph search-like call and response with our services. So let’s do that with email – and that’s where Google is going.
Google’s version of this is borrowed from another company, however. Their previous versions of “do stuff in your email” were possible only for geeks to do. You needed to install a “Labs Feature,” or use keyboard shortcuts, or do other things late adopters don’t tend to do. And what’s the solution? Apps that magically show you what to do and offer fewer choices and fewer configuration steps.
We should thank Facebook and Apple for priming customers to act this way – the app economy makes customers expect one-click actions to solve their problems. So now it will be possible for publishers like Google to create structured, in-context actions for customers to complete and interact with other systems. Some will call this backsliding and the new “Death of Email.” I call this the birth of “Email, the Operating System for Life.”