Creating My First Product From Scratch

Problem

Doing anything for the first time will inevitably include some kind of anxiety and self-doubt. Will I be able to do it? What if I fail? How will I know what I should be doing next? But, as often is the case, things will start to untangle once you roll up your sleeves and start working on the problem. At least, this is how it worked for me. One thing followed the other, and I was immensely excited to see a new product beginning to take shape.

As for the product itself, a hotel inventory management system integrated with search and booking engines made it easier and saved a ton of time for hotels either through handling booking requests or managing their inventory. This is a story of the journey that made that product reality.

Actions taken

At the very beginning, it was only one developer and me. Not many resources, one might say, and also the vast new area in front of me. But that made it so challenging. I started by putting together a problem statement. I loosely defined what we were trying to solve and started to book interview calls with potential users.

I started interviewing potential users from within and outside of the company. I explained that we were building a new solution and that I would like to learn more about their problems. I asked them to share their pain points, their experience with the existing solutions, and their expectations of a new, upgraded solution. That approach also allowed me to have free access to our competitors’ interfaces, which sped up my market discovery. I dug deep into how hotels and agencies were operating and how other stakeholders were trying to address their pain points. Most of those solutions were quite rudimentary; they were workarounds that barely addressed problems hotels were facing.

In the beginning, with only one engineer at my disposal, I had to do everything else -- conduct product and market analysis, develop a product roadmap, do a product discovery, conduct interviews, etc. What seemed like misfortune was turned into an advantage: I had all those insights in one place, could quickly analyze them, and better charter the scope. However, for the implementation phase, I needed more people. We interviewed many developers to hire the right people. In eight months, we were already four -- three developers and myself.

I collected all the requirements and created some initial interfaces and high-level prototypes that people could check out, comment on, and suggest changes. That enabled us to wrap up architecture and make the first contours for functionalities. Then we could focus on creating a roadmap based on the priorities we collected earlier. Once I completed the roadmap, I shared it with stakeholders, explaining the actions and timeline for all subsequent releases. Of course, like any other roadmap discussion, our roadmap discussion included a lot of pushbacks, objections, enthusiastic acceptance, and support. Taken all together, it brought us to a common ground and alignment on future plans.

Eight months later, we released the most rudimentary version that internal customers could use to upload contracts. For months later, and more importantly, much more feedback later, we had an ‘embellished’ version and could start to onboard hoteliers. They were able to submit their contracts, manage their inventory, handle booking requests, etc. Most users went ahead with automation, and we had to come up with an API-based solution. In two months or so, we were able to provide the API to customers who were using third-party APIs to push and pull data with high volume.

Within a year, we were able to reach out to and integrate with 40 API partners. Twenty thousand hotels were using our product, but since most hotels had multiple users, the more accurate number would be around 100 000 users. We were receiving 100 000 booking requests per minute and managed an inventory of more than 30 000 hotels. We were able to sell a million hotel rooms through different meta-search engines. It was an exciting, though taxing journey. Our team grew from two to ten members in one year, and the product itself became incredibly successful.

Lessons learned

• Don’t try to do all things by yourself -- delegate whatever you can. Of course, the importance and urgency of work will dictate what you can delegate. I find Eisenhower's Urgent/Important Principle particularly useful to help me decide on delegation. If something is urgent and important, I will do it myself; otherwise, I would make sure to delegate. Of course, not always will you have people with skills to perform a certain task, but creating processes or templates could help them acquire those skills and take some things off your plate.
• When building a product from scratch, you will often have to build a team from scratch. While more difficult, it is also more efficient since you will have a team that will grow in sync with the product. Your team would make a huge difference. Hire people who would challenge your assumptions and decisions. You don’t want the team that will merely implement your ideas without questioning them. When I was hiring for this team, I was looking for people whose curiosity and commitment could bring us added value.
• Focus on your direct users first (especially from the internal stakeholders), then focus on their manager’s requests instead of their managers who are secondary users of the system. Because any issues encountered by your direct users will most likely cause other problems served to you by their managers.
• Collect data at all times for all different user persona you targeted separately, to be able to understand their experience and needs while using the product, so you can iteratively improve it step by step.