Step-by-Step Instructions

Problems it Solves

1. What if you don't have a development team?

If you're not a developer, or don't have a development team, how can you go about providing a solution for your customers? This exercise will answer that question.

2. What is the most effective way to get product feedback?

Once your product is available to customers, you want feedback on it as fast as possible so you can iterate on it.

Guiding Principles for Building Your Utility Test

The crux of this exercise can be summarize by a quote from the founder of Y-Combinator, arguably the most successful startup accelerator in the world, Paul Graham:

Do things that don't scale.

When you are starting a company, he recommends avoiding taking actions that naturally "scale." Let's talk about why that is.

Emulating successful companies doesn't lead to success

The temptation for all of us is to try to emulate the larger, more successful companies around us. It's natural to assume that the more closely you replicate the successful companies, the more likely you are to be successful yourself.

• If Apple has great design, you should have great design.
• If Facebook has a global reach, you should have global reach.
• If Amazon serves several different segments, you should serve several different segments.

It can be easy to see all the qualities a successful company has and think it's those qualities that made those companies successful:

• Millions of customers
• A global presence
• Beautiful design
• Instant response time to customer questions and interactions
• Scalable technology

But, it turns out, your customers don't care about any of these things.

• Your customers don't care how many customers you have.
• Your customers don't care about how widespread your presence is.
• Your customers don't care about your beautiful design.
• Your customers don't care about getting an instant response.
• Your customers certainly don't care about the scalability of your technology.

You customers only care about one thing...

The only thing your customers care about is solving their problem.

You only need to emulate successful companies, to the extent that doing so helps solve your customers' problems.

The other thing to keep in mind is that successful companies don't look successful when they are starting. No company launches looking like they do when they are ultimately successful.

It's simply too resource intensive to create a "successful impression" in your early stages; especially when that impress generates little return on investment. To reinforce the point, companies that do put a lot of their effort into "looking successful" at launch, often end in failure.

Let's take a look back at some of today's most successful companies.

The Google Search actually starts by indexing for Stanford and Linux searches. It doesn't start by trying to boil the ocean: it starts with two searches. From there they build.

Facebook is the same. They did not start out trying to be the social media giant they are today with events and photos and advertising. Facebook starts by addressing a very small group of people: students at Harvard University.

Neither of these companies looked great at launch, and they certainly didn't try to meet everyone's needs. They were very small and they fulfilled the needs of a very small group of people.

Please remember:

The companies you look up to, didn't start out looking the way they do now - don't try to look like them. They started out, looking like you.

Combine these two principles, you want to do things that:

• Don't scale, and
• Solve multiple problems

You want to do things that are not meant to scale and are completely focused on solving your customers' problems.

What's the best way to solve a problem in an unscalable way: Manual Solutions.

Why manual solutions?

• Manual solutions are much faster to build.

Manual solutions are faster to build than automated ones because there is no building to do. Instead of wasting time and money building software, you're going to go out and you'll solve the problem yourself.

The functionality is instantaneous when you do it yourself.

• Faster to get feedback

When you build a manual solution, it provides a much faster way to get feedback. That's because the only way to provide a manual solution to the customer's problem, is to interact with her directly. You'll get instant feedback on how well your solution is working from direct observation, in addition to your customer's reports.

In contrast, if you build an automated solution, you will also have to build in a feedback mechanism. With a manual solution, you can get direct and real time feedback from your customer.

• Faster to implement feedback

If you are hearing what is working and what is not working in real time, you will be able to make changes instantly to your workflow, by changing what you are doing. This is in contrast to having to rebuild and then relaunch a new version of your automated solution which takes weeks, if not months.

• Less costly to build

A manual solution costs you very little, or no money to build. There is no service to pay, no development team, no designer: just your own time and brainpower.

• You don't have to write any code

This is great news for those of you who do not write code. You can still provide utility for your customers!

However, for those of you who are developers, this is where you can get into trouble.

If you write code, you know how fun and tempting it is to build an automated solution to a problem. In fact, it can be so fun, that you can find yourself justifying that it would be faster to build an automated solution than do it manually anyway.

That may be true...but probably isn't. It's probably much faster to provide a manual solution, and then automate it once you've validated it actually solves the problem.

The reason is that you will likely spend more time than you think to write the software (it always takes longer than we think), but also because you will become emotionally attached to what you have built. That emotional attachment will make it difficult to make changes based on customer feedback - especially when building that functionality took longer than you anticipated.

If you can, put your coding skills on hold for a bit longer and design a manual solution first. It will serve you better in the long run.

Example: Zappos

Zappos provides a great example of the manual solutions principle.

Zappos is currently a huge online shoe and apparel store; but they didn't start that way. They didn't start with a massive online presence, or distribution centers, or innovative logistics solutions...or even their own inventory.

Zappos started by taking pictures of shoes in existing shoes store, posting them online, and then seeing if anyone purchased them. If they got an order, they'd go buy the shoes themselves and ship them to their customer...all manually.

This is what you want to replicate. Manually implement what the automated solution will do, once you've worked out all the kinks.

The Role of Robots

Building software is like building a robot. Robots are great for a number of reasons. They are:

• Scalable
• Less expensive than humans
• Less likely to make mistakes than humans

Once you know a process, a robot is great for repeating that process over and over without mistakes. In other words:

A robot is a great way to scale a solution once you've found it.

Once you have found a solution, that is when you put your robot into play.

At the same time, robots suck because:

• They are expensive to build
• Expensive to change
• Horrible at finding the ideal solution to a problem

When you build an automated robotic solution, there is so much time and energy put into the building, not to mention the actual cost of materials or manpower. In addition, it is very difficult to make changes to a robot once it has been built.

Finally, robots are horrible at finding the ideal solution to a problem: they are programmed to repeat a process over and over again, not to look for ways to optimize it.

Throughout Utility Testing, you are on a search for the optimal way to solve your customers' problems. The goal of our testing is to find the best way; therefore, an automated solution is not what you're looking:

Your job right now is to find the best solution; not the robotic one.

An Example

To drive this point home, imagine that I asked you to build me something that would make me famous on Twitter. Imagine I had asked for an automated way to increase my interactions on Twitter to raise my Klout score.

Would your first step be to build a robot?

Of course not.

Your first step would be to figure out how one becomes awesome on Twitter. What are the right interactions to build and maintain a great community. To try to build the robot while simultaneously figuring out the best way to interact in my community would be asinine.

In this case, the obvious answer is to start with a manual solution that will ultimately inform the automated one.

Your manual solution will inform your automated solution.

First, figure out how to solve the problem. Then, build a robot to help automate the solution.

In summary, while you are figuring out how to solve the problem, keep it manual. Once you've figured it out, automate it.

Lean Startup Terminology

The practice of manually implementing solutions before automating them is common in the Lean Startup Methodology. In fact, there are at least two different forms of "MVP" dedicated to the concept:

• Concierge MVP

This is where you tell the person that you are manually, and personally, solving their problem, just like a concierge would do at a hotel.

• Wizard of Oz MVP

Similar to the concierge MVP, but in this instance you give the illusion that it is an automated process, but behind the scenes there is a manual process at play. The Zappos example above is a Wizard of Oz MVP.

Building Your Utility Test

Let's figure out exactly what your manual solution will look like.

You'll start by referencing your Potential Features list from your previous exercise, focusing in on the three Utility Testing Versions that you identified.

Now take out your Building Your Utility Test worksheet.

Step 1

In Column 1: Feature, write in your three different versions, or features, that you will test.

Next, you have two opportunities to fill in solutions.

Step 2

For your first set of solutions, think about:

What does an automated solution look like?

Now, your answers here do not have to be right, and you may not even know the answers at this point.

What this step enables you to do is to clearly differentiate between Manual and Scalable solutions. This way, you can capture any visions you have for Scalable solutions, write them down, and give them a place to live while you work on your Manual solutions - which, again, will be faster, easier and cheaper to implement.

For my first feature, Step-by-Step Exercises, my automated solution would be Workbooks. I can take these exercises, put them together, and make them available for people to download on their own.

For Accountability, I could create Virtual Peer Groups where I connect founders with each other and they keep each other accountable. In this way it's scalable because I wouldn't be directly involved on a day-to-day basis.

For Encouragement, or keeping people motivated to continue on, I could create gamification and community support so individuals could get their own rewards for completing various tasks toward building their company.

Again, these are all Scalable ways of doing this: ways that do not require my Manual intervention. These are my robots - they eliminate me from the process.

Write down your robotic solutions.

Step 3

In this step, you will think about what you can do manually to try to solve the problem, to make sure that you can solve the problem before building an automated solution.

In my case, instead of publishing a Workbook, I can have 1-1 Mentoring calls with founders. I can reach out to founders who read my blog or attend my workshops and offer 1-1 Mentoring sessions to help bring them through their own process. That's actually where all of the exercises that you are doing now come from: from real experiences working with founders in the Manual stage of this process. This is how I was able to validate that the exercises included in these workbooks truly solve a problem for founders.

What does this look like for Accountability? The Manual version of this feature is to set up bi-weekly calls with founders to have check-in sessions. Instead of having other founders hold each other accountable, I can hold them accountable individually.

Finally, for Encouragement, I can manually send emails to congratulate founders on their accomplishments and check in along their journey.

All of these Manual solutions are easy to implement, do not require building anything, are cheap and would be easy to alter if they did not solve the problem effectively.

Once I validate they solve the problem to the point that I can achieve my Victory, I can begin automating them. This is covered in detail in the Scaling workbook.

Once you complete this portion of the worksheet, you'll know what to "build" your Utility Test.

What's Next

In this phase of Utility Testing, your job is to validate a manual solution. In the next workbook, Scaling, you will automate that proven, validated solution.

In this chapter, you've discovered that not only do you not need a development team, you probably don't want one.

You've also discovered that the fastest, most effective way to get product feedback is to build a manual solution, where you are intimately involved in solving the problem for the customer.

• The fastest, most effective way to get a solution to your customers is by doing it manually.
• The fastest, most effective way to understand whether your solution works is by doing it manually.
• The fastest, most effective way to adjust and adapt that solution is to do it manually.

Next up, you will learn what to measure in your Utility Test to ensure you are finding the best way to solve your customers' problems.