This article was published on December 20, 2017

How your startup can design a product without breaking the bank


How your startup can design a product without breaking the bank

Have you ever wished to take an idea and turn into a product?

But are constrained by limited resources?

Well, worry not, this post is all about how you can design and build a product without burning up all your resources. Great tactics to build a product without breaking the bank, trust me, I’ve used them myself.

When it comes to design, limited resources, and the resulting constraints force you to be wiser and more innovative in tackling challenges. To keep up with the curve, if not beat it, I came to realize that there was a need to prioritize well and keep things lean. At the nascent stage, requirements and challenges change so fluidly that being flexible and ready to adapt is a must.

Two years ago, me and my team set out to explore how we could make it easier for remote teams to collaborate better on design heavy projects (read: almost every digital project today). With dispersed and remote teams, the design and development challenges when tracking tasks and exchanging feedback becomes more intricate.

The 💜 of EU tech

The latest rumblings from the EU tech scene, a story from our wise ol' founder Boris, and some questionable AI art. It's free, every week, in your inbox. Sign up now!

Many first time entrepreneurs feel like they have to build it right and build it big in the very first go. Well, I’m here to tell you it’s no problem starting small. What is important to get right in the beginning is identifying the problem you are trying to solve and how your product accomplishes that.

As a founder, I came to realize that you have to focus on multiple aspects of a product early on. You have to design the product experience, create a cohesive brand and messaging, set up a go-to-market strategy, and above all manage these tasks with limited resources.

Having worked in a large product company at enterprise scale, this was a big change in my mindset and operational surroundings when I started building my own product.

So, how does the process differ ?

There is no product — only the problem

At an early stage, I was sure that the core problem we were trying to solve was a relevant and concrete issue. While doing QA services for clients based in the US, our team had to go through a lot of hassle to collaborate on projects with clients in a different location.

We took screenshots, annotated them in SnagIt, and then discussed them over numerous emails or Skype calls. It was very tedious.

Research your users and conceptualize your solution

When we first tried to find solutions to this problem, we came up with many concepts. It can never start with just one solution. There are so many different aspects to a problem and narrowing down to just one side of it in the beginning is very short-sighted.

We talked extensively with our users, tried to understand their process and workflow, checked what tools they used and how important was the problem to them. This gave us a better idea of if and how our product would solve the problem for these users.

Focus on one objective and get it right

In the beginning we could have chased down multiple alleys, with all the different concepts that we had brainstormed. But that would have meant we couldn’t dedicate ourselves completely to one objective and that would have also meant resources being divided and distributed.

For a small bootstrapped team like ours, that would have been an inefficient scenario. It’s easy to lose your path in the initial stages in wanting to do everything and providing every little feature that we see in the products that we use. But often, in the quest to build everything, the main function of the product can become muddled. Basically, the ‘Aha’ moment often gets neglected.

Focusing on the core issue helps build an identity and differentiate the product. Rather than adding features by the dozen, I am an advocate of getting the fundamentals right and ensuring that user’s central pain points are addressed in every way possible. If a product can achieve that, then it has a much better chance of retaining users. For all the hard work we put into getting new users to sign up, all that is a waste if the users do not stick around and give up after initially signing up.

Adapt with feedback

We went back to our users for feedback with the product solution we had created. Taking onboard feedback from end users is very helpful. It aligns the product roadmap with the actual needs and pain points of the user. For a team to be able to accommodate feedback quickly, a certain degree of agility is necessary.

Being able to pivot based on user feedback is critical when working with limited resource, like we were. At this point, the original product can change and evolve. It’s important not to get too attached to the original product and be flexible.

Validate with your users and prospective audience

At any stage of product development it’s important to validate with users. After incorporating internal and external feedback into the design, take it back to test with users and run experiments. For an early stage product, it’s even more important to focus on prospects and beta users because getting buy-in with them creates faithful evangelists for the product.

Another great way to validate is dogfooding. We let our team and internal stakeholders use the product exhaustively. Using the product day in, day out will put you into the user’s seat and help unearth any issues that may have missed in the development process.

Don’t overcomplicate

When starting out, we wanted to to keep the user experience as fluid and simple as possible. But we did not want to add bells and whistles before validating the idea and product. So how does one build, launch, and keep on improving the product without a designer on board?

To do this, we’ve always tried not to over-engineer or overcomplicate features. The navigation and messaging in the tool have been one of the foremost ways to achieve this. Over various iterations, we’ve ensured that users can access features and functionality in as intuitive and hassle-free a way as possible.

When building our initial prototype and getting things off the ground, we used free resources wherever necessary, like images for generic placeholders, color palettes to decide on visual combinations, etc. — and I recommend that you do the same. Also pay attention to the aesthetics and workflows in other popular apps to get inspiration. For example, rounded corners, standard placements of navigation bar, and pop up messaging are all commonly seen interactions.

Iterate and improve

Design, feedback, and validation are the core parts of every development cycle. Each cycle helps iterate towards a better version of the product. Collaborate with internal stakeholders to find the right solution, and adapt rapidly. Drop what is not working and move on to the next iteration.

Conclusion

Each startup has its own journey from ideation to creating a market fit product. The ones that focus on the problem more than anything reach a stage where their idea floats much faster than those who don’t. One of the most important things creating my own product has taught me is that users are the core of a successful product.

Without having a dedicated set of users who actually find value in your product, you will not reach the ‘Aha’ moment in your entrepreneurial journey. The way we have managed this is to listen carefully to our users and be faithful to their needs.

I hope like-minded entrepreneurs will find some inspiration from reading about our journey.

Get the TNW newsletter

Get the most important tech news in your inbox each week.

Also tagged with


Published
Back to top