Lean Startup

Instruction for Startup owner. Part 2

How to lose your money, time, investors and the market. Vision, goals, and requirements.

#Back in time

In the previous article I introduced Mark, who is an entrepreneur and is working hard on his great startup. He hired a software development company to build his product. After some months of development, he found that developers are not delivering what was promised and finally he stop the collaboration. 

His thought was that chosen supplier was a band of amateurs so he started talking with some other companies and asking them if they can overtake the development, but after some investigation, all of them answered that the code is sloppy and crappy and to be honest the best option is to rewrite it from scratch. Additionally, there is no documentation required to be able to work further on the code.

The first part of the series is available here

Today we will help Mark to figure out what mistakes he did and why his collaboration ended in such a sad way.

No alt text provided for this image

#Problem to solve

The first challenge for Mark was a problem he wanted to solve. In software development problem is described by requirements. 

The requirement is a thing that is needed to be solved in a solution. In Mark, case requirements were described in two forms. First were wireframes and later designs which were a 'visualization' of the desired look of the application. Other form were user stories - a popular way of describing what solution should answer to.

What mistake was made here? 

The biggest one was that the whole concept was not well explained to the developers. They didn't have a good business idea feeling. It caused that their approach was more to deliver lines of code, and not necessarily on solving a problem. 

It's essential that the whole team involved in a project will have a feeling of the mission - the team is a part of something significant what can have a massive impact on desired users. Mission where everyone knows, understand and feel that this impact is significant to users. 

In this case, it didn't happen. For developers project was just a collection of user stories prepared by Mark based on some guidelines from the project manager from a software company. 

When Mark prepared them, project manager validated if they are complete, but there was no any phrase to see if these user stories will be enough to deliver a great product according to the vision and be still in a budget. Pushing on a reasonable price was the most significant problem.

Next, a whole team discussed wireframes, user stories and after two calls they decided that they can start with development. 

No alt text provided for this image

What worse user stories were not defined well. They were written down as a list of tasks without putting attention on the real value of the user story. So when a user story is valuable? When should we implement ANY user story in our project? The answer is simple:

Only when user story brings some value to the user. This is so simple, but in most of the project it's missing.

The next problem was that all these discussions were not written down in any form. During these calls, the whole team was digging into details, implementation. No one defined acceptance criteria. This is also an essential thing in software development. Acceptance criteria help to set for everyone involved when a feature is delivered.

No alt text provided for this image

So user story answer on question - WHAT we should deliver. 

If a user story is well defined then also answer on question WHY we should implement it at all. However, user story never answers on question WHEN we know hit user story well implemented. Moreover, here is a place for acceptance criteria. They explain precisely on a question WHEN user story is well implemented. 

Lack of acceptance criteria was the main cause of problems in a ping pong phrase. Understanding of this how features should work was very different by stakeholders. As I mentioned they had some discussions three months earlier, but no one remembers it exactly, and what worse it wasn't written down. 

Well defined acceptance criteria are also beneficial when after development we need to validate if the delivered feature is working as expected. They are for us form of checklists - if the feature is fulfilling each acceptance criteria, then we can be more or less sure that it works as expected.

This technique is also beneficial for testers who are responsible for assuring quality on a proper level in a project. They don't spend time on figuring out how the application is working, but they have clear guidelines on how we expect that feature is working. It's much easier for testers to test such a project.

# Non-features

The next very important this which wasn't taken into consideration was no definition of non-technical requirements. Always if you are going to build any solution, you should consider not only how your great application will look like, how logic will work, but also you should think about such requirements like the estimated amount of users who will start using the app? If the application will not crash when 100 users will try to register at the same time? 

What will happen when the amount of data in the app will blow up, and the app will start to be very slow and unusable? Alternatively, the user will have to wait 5 minutes after application start on loading of everything needed?

Another example of a non-functional requirement is what should happen when your internet connection is lost? Should we show anything to the user? Alternatively, maybe there is a need that some features will also work in offline mode?

Lot, lot of questions, but if you do not spend some time on adhering them, then it will back to you at the end of development or... what is even worse when you will release production version of app, you will get the market and then suddenly you will see that users are very disgusted and stop using your app and you will lose much money, time and maybe your whole business will be killed even before it will grow.

No alt text provided for this image


# Summary

We touched only few - but very important parts of this what should be defined before we start developing new application. Mark learned from it a lot. I'm sure that he will never make the same mistake.

In next part of series we will go with Mark through a solution domain - what we need to know to deliver a great application. 

Acute a problem is a must, and it's a first important step. However, requirements don't answer on next important question HOW we should implement the solution to answer on WHATWHEN questions.


Do you have a different question?

You did’t find the answer to the question bothering you? Write to us! We can help!

Leaware SA, with its registered office at 86/1 Perkuna, in Warsaw, is the controller of your personal data.

Similar posts

Case Study

Insurtechs – How to take a bite of a cake worth billions of euros?

The financial industry, like most segments of the market, has undergone a decade of digital transformation. The result is the creation of increasingly powerful financial firms operating in the financial sector, called ‘fintechs’. Their strategy is to use state-of-the-art technology from product development, sales, customer contact, and consumer relationships.

Zbigniew Waz

Customer Development


After LPCC meetup in Luxemburg where, together with Joona Mäntyvaara we were talking about "Building the right software and building it right", we have got a lot of question from you! Thank you for that! That’s why we decided to record first Q&A session about Behaviour Driven Development (BDD).

Tomasz Soroka


Let's stay in touch!

If you want to know more about how we can help you or you like to be on a current basis, please leave us your e-mail.

Leaware SA, with its registered office at 86/1 Perkuna, in Warsaw, is the controller of your personal data.