This post was written by Gev Balyan. Gev is the founder of ucraft, a website builder, headquartered in Armenia. He explains why he deleted hours of work and decided to start again and why that made ucraft a better company. He also shares important startup lessons learned.
Imagine deleting 3000 hours of your colleagues’ work. Well, that’s exactly what I did. And no, it wasn’t a mistake. I purposefully erased our company’s entire new platform.
I had a clear vision for the product – what it would look like, and what functionalities it needed to include – and I thought the developers would seamlessly be able to carry it out. But, when they delivered the demo to me three months later, I hated it. I thought it was impossible to fix. So, when the developers went home for the evening, I erased thousands of hours worth of code.
I broke the news to the developers the next morning. And although they were angry, the experience did help them to become better at their jobs down the road. Moreover, it helped our whole team to work more in unison. Here’s what we learnt along the way.
1. Expand your knowledge and communicate
If your vision and your team’s technological capacity don’t match, you have a problem. While you don’t need to know exactly how something works, as a founder you should be aware of both the limitations and skills of your team. It’s about setting expectations: when you ask for a unicorn and you get a pony, your team has missed the mark.
Understanding what your team can produce from the start is essential. But your team needs to communicate what they’re capable of as well – it is on them to fulfil your mission. And if they fail, they have to own up to their responsibilities, too.
2. Choose the right resources
Using the wrong resources at the start will prevent you from scaling your product. And when it comes to code, you can get stuck on a certain step because of unsound technologies. If your platform features a misguided UX for example, you might not be able to add new functionalities or features down the road. A video or additional text boxes, for example, may not be supported.
So, by considering your final vision and by using the appropriate technologies from the beginning, your team will get started out on the right path.
3. Define your MVP (minimum viable product)
When startup founders have a vision for a platform, they often want to build everything at once. But trying to do this complicates the building process, and the platform can become too large to handle – so much so, that the quality of the product may diminish.
Instead, founders first need to think about what their users really require in their platforms. They need to develop an MVP. To figure out what your company’s MVP should look like, get in touch with potential customers via community forums, Twitter, Facebook or Linkedin and ask for their input – what features do they most desire, and what can’t they live without? Once you gain these insights, adjust your MVP and continue product development based on their feedback.
4. Inspire your team
You need to put yourself in your employee’s shoes. Remember – they don’t own the company, and they aren’t always the visionaries behind it. So, it’s up to you to motivate your team to come into work each day with a positive attitude, ready to work their hardest. Although we learnt this takeaway after-the-fact, we know now that an inspired team will almost always create a product that’s up to standard.
5. Give the right task to the right person
Don’t force someone to do something they don’t like doing. If, for example, one designer is art-driven but hates creating UI, don’t give her UI tasks. She’ll get bored, and will likely have a hard time delivering something of high quality. You’re better off delegating tasks within your development team based on their interest and strengths, setting each team member up for success.
6. Sometimes it’s better to completely remove what you have
Imagine you need to fix an unsafe tall building. But the building doesn’t have a solid base. You’re likely better to just tear the whole thing down and build it again, because well, a quick fix wouldn’t be very durable. If a platform isn’t working correctly, it’s better to just start from scratch. Instead of wasting hours trying to fix the core, you need to start again by creating a stable base.
Even though deleting my developer’s code was a harsh move, it did teach us all plenty of lessons. All in all, the experience helped to bring our team from amateurs to professionals.
1 comment
Gev,
I am not suprised! In a company where planning does not exist, it is very normal to expect this sort of issues. All the points you mentioned above comes to one point: PLANNIG and as long as you do not have it you will repeat the same issue.
Anyway, I am happy you understand that communication is important at last! I hope other seniors in the company understand it as well.
Comments are closed.