Warning: "continue" targeting switch is equivalent to "break". Did you mean to use "continue 2"? in /home/brain/domains/huboftech.io/public_html/wp-content/plugins/revslider/includes/operations.class.php on line 2854

Warning: "continue" targeting switch is equivalent to "break". Did you mean to use "continue 2"? in /home/brain/domains/huboftech.io/public_html/wp-content/plugins/revslider/includes/operations.class.php on line 2858

Warning: "continue" targeting switch is equivalent to "break". Did you mean to use "continue 2"? in /home/brain/domains/huboftech.io/public_html/wp-content/plugins/revslider/includes/output.class.php on line 3708
Workshops as the beginning of any journey - Hub of tech


As a software and r&d company we get a lot inquires that are written in a very poor quality “I have an idea for a Facebook for recruiters, etc”. You know the type – one sentence which is followed by another magic one “how much would it cost”. I think you can see the irony of putting those two sentences together.

It’s cool they have simple ideas, but let’s face it – they are not described at all:) In order to run ANY kind of estimations some more detailed information is definitely needed.

Sometimes the founders will have an experienced person among them that are able to write more detailed descriptions or even user stories with diagrams. But that is rarely the case.

That is basically who the idea of Workshops or Sprint 0 was introduced and is heavily used whenever dealing with starting a software journey.

The concept is fairly simple (regardless of the workshop framework assumed). The client should meet with a team (usually a salesperson + project manager or business analyst together with an engineer and maybe a designer) to discuss in depths the product. 

As you may have read in a previous article (“How to be mature as a startup”) there are some basic steps you should do before meeting with anyone:) Let’s assume that you have those items and now you are about to meet the team.

What you should expect?

Basically the main goal of any software development in a greenfield (build from scratch) project is to come up with the MVP.

What is an MVP some might ask – it’s definitely not “most valuable player” – the shortcut stands for Minimum Viable Product.

In plain English, it’s the first version of the product that should be able to validate basic assumptions.

Let’s take an example – you want to build a system for tour organizers. You know that their main issue is the time spent on preparing all the agreements. So in your MVP, you should focus on solving this pain. Do not add unnecessarily, yet shiny features like mass communication, etc. Focus on the biggest pain point. All other things you have in your mind (and it’s good to have those) should be pushed into the next phases.

Speaking of phases:

The workshop result doesn’t have to be only about MVP. It can include some future phases, which basically should be the solutions to next, less important, pain points of the client.

NEVER do a feature just because you like it. Always focus only on your client’s needs.

So During the workshop, you will be usually going through all the business requirements. You should be able to describe your users (or personas). This will allow the team to write specific scenarios for each action. For example “As an administrative user of a travel agency I should be able to generate an agreement after entering the profile of the reservation”. Simple, yet very effective. Of course, the user stories should be as elaborative as possible, including so-called “edge cases” which should cover all unexpected behavior that can be done by the user.

During the workshops, once the business requirements are known, and the end-user is described the team should think of a way to make the product as lean as possible.

What does it mean in practical language?

I will use an example. Let’s still stay on this system for tour organizers. Let’s say that it should be a SaaS-based solutions. Most people whenever planning the work of a SaaS want to introduce automatic payments for the product from day one. But to be honest, only few percents actually need it. Payment is something that usually for the first few months can be done 100% manually. This approach will save you a lot of time and money that can be used to solve user problems (unless automatic payment is actually the problem, but that is very rare).

So at this point, you would ask, what should be a typical effect of a workshop? 

I’d say that for sure the documentation (detailed one) when it comes to MVP. Some smaller descriptions of next phases and features (it’s important to know what’s the vision, so certain parts of the system can be implemented in a way that is ready for new things to come).

Most of the time I’d expect to have lo-fi mockups that represent the user flows (they even can be clickable).

And the best part of the whole process is that once you have this type of document you can actually send it to other companies as well to get an estimate. Only, in that case, you can actually compare the estimates, because it will give the engineers running them a clear overview of what needs to be built.

What’s more – there are some companies that are actually specializing in running only workshops. In the beginning, it may seem like a big investment (usually a workshop costs a few thousand dollars) but believe me – it will save you a lot of time and money (i won’t even mention time-to-market) in the future.

If you have an idea and want to run a workshop, do not hesitate to contact us. We will help you find the right approach and guide you through the process!