Building a pilot. The story of a startup - part II

We are glad to present you the second part of a small series of articles devoted to the history of creating a startup. In this part, we will talk about how we built a working prototype, what problems we encountered, how they were solved and, most importantly, how to avoid such errors / problems and what we should focus on to achieve maximum results in the shortest time.

For those who have not read the first part: How ideas are born.


')
Baseline data . Just want to note that one of the most important parameters for a successful start - the team - we already had. Therefore, we do not consider this question in this cycle. And, as is known from the first part, we already had a document describing all parts of the project.

August 2008 Divide. The first thing we did was split the work into several large pieces. In our case, these were: the website, the service itself and the Flash editor. Each part was worked by one person. Every week we held reporting meetings where each team member told about his achievements / problems.

Here at this stage we made the first mistake . Meeting once a week is very small for quick pilot development. Schedule a meeting every day! The duration of the meeting should not exceed 30 minutes and each meeting should be divided into stages. We brought the following steps for ourselves:

• Analysis done / not done in iteration
• Discussion and problem solving
• Planning the next iteration
• Are we going there? (this item came to us later, there will be a story about it later)

Each meeting should “on the exhaust” contain clear tasks for each participant. There should be no allegory and too large tasks (immense) in the framework of the iteration.

September 2008 We collect and test. After about 5 weeks, we had the first build of the working version, which could be called alpha. It took us some time to catch the most obvious bugs and flaws ourselves. After that, we sat down at the table and wrote a plan for improvements to the next stage.

And here we made the second mistake , which, thank God, was understood before all our improvements were implemented in the second stage. The error was the absence of third-party testers. Your entire team will never be able to test your service in terms of solving the very client problem we are aiming at. The whole team will already have a “zazyleny look” on the service.

Therefore, immediately (I repeat - immediately) involve third-party testers. Let it be friends, acquaintances, colleagues (not participating in the project), relatives, no matter who (the main thing is that they have the task that you want to help solve). And here it is very important to understand two important points:

• Do not ask them to find bugs or flaws. That you yourself can and this is not important at this stage.
• Ask them if your service solves the problem / problem? And how convenient it is for them.

In our case, it looked like this:

Task:
Service designed to simplify communication between team members who work on visual materials. Minimize misunderstandings between the designer and the client. All team members enter and leave their comments directly on one or another layout, others see the comments left and can respond to them. (we added an invitation to the service to the task)

What we expect from you:
Tell us if you managed to solve this problem within your project? How easy was that? What problems have you encountered?

And then the truth was revealed to us - we missed, we defocused our attention. Instead of concentrating on the functionality that solves the problem, we made a huge amount of tinsel. They did it because it seemed at the meetings - “but what, this is useful!”

So, approximately, our alpha version scheme looked like:



More than half the time, we can say, wasted. Because these functions were either not necessary to achieve the goal (but useful), or completely unnecessary! And here it is necessary to immediately add clause 4 to all working meetings (it was marked gray above), which says “Are we going there?” Always ask this question!

October 2008 Breaking . For another 6-7 weeks, we broke and rebuilt almost everything. Each function has been revised and changed its mind. It remains only what is really necessary or what is already more expensive to break :) As a result, because of this error, we have lost almost 2 months. But, all is well that ends well in November, 2008, we received a ready-made alpha, which looked like this:



Universe project. Based on our bitter experience, we have developed for ourselves the “project universe” by which we evaluate certain functions. Here is a small example of this universe.



As you can see, the closer to the center of the functionality, the more it corresponds to our common goal and, accordingly, it must be implemented as quickly as possible. What we get in 9-10, we just throw out. Do not be afraid to throw out! Even if one client asked for a feature, be able to say NO! It is important!

The same universe can be portrayed not only for development, but also for marketing. Where and how to advertise the service, where to promote and by what means.

It is possible to come to an ideal service if all the points up to the 8th one tend to the center and get into it in turn.

November 2008 Alpha! In November, we didn’t have a working version, which could already be called alpha! But before the beta and RC is still far away :-) This is in the following sections.

---

At this stage, everything. We have a pilot who works, who has already been tested not only by us. Now is the time to move towards receiving investment.

---

Briefly about the main thing

• divide the work into parts, do not try to grasp the immensity
• meet every day, it will allow you to quickly come to the result
• use third-party testers, let them tell if your service is performing its task
• do not do too much, everything that is not related to the solution of the problem is on the table, then you will lift and think
• and again - do not do too much, focus on exactly what your service should do!

Further in our cycle:
Part III - received money, lost money . About the terrible experience with the investor, what to do and what not.

Previously it was:
Part I - how ideas are born.