During the first few months at my start-up, we built an early version of an event app platform to engage conference audiences. We sold our product to a few conference organizers. One of our ideas was that event organizers would love the ability to make changes to schedules on the fly and they would want to notify the attendees about these changes. We had two parts to our solution: an admin console that could be used only from a laptop and an end user-facing mobile app. The problem was that our customers (the event organizer) wanted only a well-designed, visually-appealing, and white-labeled app. They were willing to pay us only for the solution that would amplify the value they were providing to their customers. The event organizers rarely used the admin console. They sought our help whenever they needed to use any functionality in the admin console.

When we sat down as a team, we observed with dismay that the organizers never or rarely used real-time notifications. We jumped to the conclusion that they were not using them because they were accessible on a laptop and not on their mobile phones. I remember we spent three hours having a heated debate about the best way to solve this. We wanted our platform to be a DIY platform. We came up three ideas: building a mobile admin console, creating a WhatsApp-like chat, or notifying the attendees using SMS. All our ideas were based on two big assumptions:

After our three hours of healthy discussion in our start-up team, we realized that none of our customers had complained about not being able to send notifications to attendees themselves so far. We didn't know if it was because they didn't know about the feature or they didn't use it because it was available only on the desktop admin console. We, once again, jumped to the conclusion that the customers actually needed the ability to send notifications but weren't complaining. So far, our customers had always called us a day before the event and relied on us to make the necessary changes from the admin console. So, we threw open more ideas to somehow build this into the product so that it could become a DIY (Do-It-Yourself) value proposition. We could never reach a consensus on what that solution would look like. There was other functionality that customers were asking for, and we had limited resources. So, we decided to wait it out, while gathering data, observing, and talking to our customers, before we decided on an approach. In retrospect, this was one of the smartest things we did.

Over the following eight months, we had one or two occasions where conference organizers wanted the ability to send notifications themselves. They told us that they couldn't bring a laptop to the venue. On those occasions, we charged them extra, and sent in an intern and a laptop to help during the event. We eventually built the feature enabling notifications for more than a year, and 40 conferences, later. We built it mainly to reduce our operational costs rather than as a benefit to the customer. It was not sustainable to send an intern and a laptop anymore. So, the feature was built in with an unpolished UI and with just enough functionality that we had seen used in the past year. All along, event organizers had expected us to support them with last-minute schedule changes.

We thought that by making it easier for our customers to send notifications and the feature accessible on mobile we could increase our revenue, because event organizers would be willing to pay more for a DIY feature. While they were willing to pay more for the functionality (of making real-time changes), they weren't really keen on the DIY aspect. If anything, it added more to their workload, and they were extremely stretched and the time constrained during the days of the event already.

We realized that this feature was not a revenue generator, but a cost saver. Since the organizers were always leaning on us to help with last-minute changes, we had to find the best way to optimize our costs and time in responding to their requests. We would have had to take a very different approach had we wanted to turn this into a revenue generator, and that could have been an undertaking that we as a team may have been unprepared for.

There was nothing wrong with the ideas that we had. What we didn't know was the impact our ideas could deliver. A reflective pause is essential between an idea and finding the best way to implement the idea. The reflective pause should help us to understand our users. It should also help us to understand what we would gain as a business from our idea and make it possible to define and plan for the success of your idea.

Often, we tend to look at the product features in isolation. We prioritize features based on relative merit, rarely questioning if a feature is needed at all. In the case of my start-up, we could have made the mistake of evaluating if SMS notifications were more valuable than the mobile admin console. However, the more important questions were: do we need this feature? Is there a better way to deliver the value proposition without building anything more than what we already have? Should we instead build something else more valuable? For us, customer acquisitions and conversions were the most important business outcomes. One way we could have validated the value of this feature was by explicitly creating pricing plans, which excluded/included the notification feature and validated if it impacted our acquisitions. We could then have asked: are our leads converting because we have this feature? Are our customers opting for the plan that includes notifications? We hadn't been very smart about this, but at least we learned an important lesson! Prioritizing features requires finding that fine intersection between "why," "what," and "how." Let's begin with identifying the product features.