How this came about?

The company I am consulting for handles events for many big organisations. Some times, when the same big clients ask if we know of a service where we can do X, Y and Z, we weigh the benefits.

Most at times, it is far less of a hassle to use any SaaS that does anything close to what they want and find a compromise. On occasions like this, we also weigh the benefit of owning such a tech as opposed to using what is already out there.

We have a tech team, and I was tasked to build this one from scratch. Due tot he time constraints, I planned and designed this entire app, almost entirely by how we would have wanted such a product to be.

Tight deadlines, gets things done.

As much as we would love to deliver earlier than a client expects, some deadlines are just beyond ridiculous. But miraculously, we do get it done.

The client was firm about the deadline. They gave us full creative control, but just requested that we be able to test it out a day prior, during the rehearsal. That did not happen.

Research & Analysis.

Like the story goes, if given an hour to do a job, spend 3/4 of the time planning and 1/4 on the execution. For this case however, it was too cramped a time from the moment they reached out to us, to the time we had to start as soon as their Finance team approved the budget.

There were very few reference material that I could find online. Not to mention, the rush to get the devs working on it was also crucial. They were chasing me for any screen, any feature they could immediately get started on.

In that frenzy, I collected my thoughts and immediately got to work with my handy pencil and paper. I wrote down the use cases, and identified as many edge-cases as I could.

Working on fresh new ideas are great, but during the planning, you cannot find all the possible cases of scenarios to address.

Your planning can be meticulous, but more often than not, there will be some surprises as the feature is being built. Why do you think there has been so many high profile tech companies have demos that crashed on them in front of millions?

Since this product was also meant to serve both an online audience and people on-site, viewing on a large LED wall on-stage, we also had to take those design constraints into consideration.

Inevitably, to make this product something that can serve future customers, we had to have a backend management system for the contest admins.

Design.

The front-end user facing screens were quite straight-forward. But it was necessary to understand the entire flow of how a typical contest is held and how it usually goes. This allowed me to quickly dream up how the admin backend should look.

Because the admin backend is for event admins and people like ourselves, I did not need it to be super fancy. It just had to be functional and every button should be something that is necessary.

Reusing components, for dashboards, saves time.

Although this can be applied to any part of the site, I prefer building the user-facing features from scratch, to avoid creative laziness.

To get something out to the Devs at record speed time, I designed the basics of some of the backend dashboard. This included things like the sign-in. what contests are running, creating new ones, etc.

As I approached the CRUD screens, I started planning out the database schema as well. At this point, I knew although it was doable, it was going to take every team member’s effort to pull this one off.

Development.

After tackling the dashboard, I made a couple of iterations and tried my hand at the front-end side of things. Picked out the animations I wanted and the desired effect to try and get my mockups as close to what I want.

The devs started work from day one, and on about Day 6, they started on the front end side of things after I had run by some designs with the client and gathered all necessary inputs.

Being able to talk the same language as your devs, helps the relationship.

Even though you do not necessarily have to be technical in order to manage a Product, I have found it very helpful for me when building a relationship with tech teams. Being less technical, I am able to wear a different lens to look at the same problem.

End of the day, it is only when your relationship with the tech team is right, that you can at least brave the waters together. If it is rocky from the start, I would highly suggest not undertaking such projects.

The tech team needs you as much as you need them, to deliver to the clients. When the urgency is there, the last thing you want is a bunch of disgruntled tech guys refusing to make things happen.

Ship to customer and their reaction

On the day of the company’s Dinner & Dance, we officially tried out the product. If there is any advice I would give from this project, it is to always do thorough testing at least 2 days prior. We were rolling the dice with this one, just because there was a delay in having the project green-lit.

Skeptical at first, joy at last.

We were handling the entire event, and there were much bigger moving parts that is way more complexed and crucial to the show, but everyone only had their eyes on the one thing. The prizes! As the first name rolled out, we knew it was not going to disappoint.

Even the liaison for the company was taking a huge chance with us. She personally thanked us repeatedly, for having nailed the project exactly how they had imagined.

This project gave us an idea about how fast we can actually ship, if we want to. It also showed me, there is always room for competition in such a niche space. More often than not, companies would love to use your tool either as a primary or secondary solution.

For the nature of the business, it never hurts to have more than one standby for any given section. You literally only have one shot to make sure it does not go wrong mid-way. And if it does, the peace of mind knowing there is a back up to pick up the slack, just puts minds at ease.

‍