How Your Needs and Pains Influence What we Build

Busywork is a young company with a product that has just started to take shape.

It all started with our idea. Now you are shaping that idea into a product. Without talking to you, we wouldn’t know if our product evolves to match the needs of our customers.

At Busywork, we use the lean startup model, as described by author Eric Reis. By involving users in the iterative process of building, measuring, and learning, we create a product that the user wants, stripping away any assumptions that we might have.

So how have we done this, so far?

First, we had to seed the process. Without customers, we would have no feedback, and without something built, we had no subject to feedback.

Having an idea of who our customer could be, we started reaching out to people. Directly sending cold emails or contacting them on SoMe. We presented our value proposition to them. 

Make a deploy serverless backends without coding

From the responses that we received, we settled on a small group, ten people.

The minimum viable product

Visually building no-code backends

The big question: What should we build? Answer: As little as possible. 

The goal was to get as much feedback from our select group as possible with a minimum effort in terms of building a product. From our value proposition, we extracted the key features that would make up the initial MVP.

  1. Visual builder. The core of the product. It allows customers to build backends by connecting building blocks.
  2. Easy deployment. One of the biggest hassles after making a backend is the deployment. How do you get it from your editor to the cloud? Without too much manual work?
  3. Building blocks. The blocks that enable anyone to build what they want. And to make anything, we needed an initial group of blocks. 

What have we learned so far?

We have learned a lot. From our perspective, we naturally have some hypotheses about how our product should work and how a user will interact with it. And we have been tested on our belief by our private beta-testers – which is excellent. 

The diversity in our select group has meant that we have gotten a lot of different perspectives on the user experience of the product. Since our group contains both designers and programmers, it doesn’t come as a surprise.

Through feedback, it was clear to us that the process of visually building backends should be intuitive and to a degree, guided. Some of our testers are front-end end web developers that are used to autocompletion within their editors. They felt this feature was missing in our product.

No-code is focused on ease of use

For our product, we always balance between ease of use and flexibility. It’s simply not possible to allow for all kinds of atomic operations and at the same time, have great UX. 

So how are we balancing this?

For now, our focus is mainly on no-code. We want to democratize backend development. We want to enable people to make. And most of our testers agree that we can only accomplish this by having a gentle learning curve and a visual programming environment that guides the user.

What will we do next

This write up is a conclusion to our first many iterations. Having reached a point where our testers request more building blocks than actual feedback, we are getting ready to launch publicly. With the launch, we are looking forward to talking to even more interesting people and to learn how they use our product.

The public launch is still about a month out, so we would be interested to hear from some of you who have signed up for early access. Let us know in the comments what problems you think that Busywork can solve for you.

We have a lot to share about our product and journey. In the meantime, please subscribe to our blogfollow us on Twitter and sign up to get notified when we go live.