From experience, I know how easy it can be to over-engineer a feature nobody actually wants, or succumb to the sunk-cost fallacy and continue down the wrong product path for too long. To counteract these mistakes, you need to build a habit of constantly questioning your decisions – of keeping the bigger picture in mind.

Regularly asking yourself and your team, “What problem are we trying to solve?” and following that up with, “Does what we are building solve that problem?” can lead to profound insights. This kind of meta-questioning has saved us a few times at SharpestMinds from getting lost in the weeds and building the wrong thing.

One such occasion occurred shortly after we had pivoted to become the marketplace for data science mentorships that we are today. I had recently made the tough decision to scrap our old code-base and start from scratch. Instead of waiting for the software to be functional, we posted a signup form on our website and the founders began running the business out of their inboxes – connecting potential mentees and mentors, setting up interviews, and kicking off mentorships.

So far, so good. We were following standard Lean Startup protocol – launching as early as possible to start testing and collecting feedback. Doing everything manually wasn’t sustainable, of course, so my job at the time was to automate away as much of that work as possible with software.

A big chunk of that manual work involved coordinating interviews with mentors and potential mentees. It seemed, then, that scheduling meetings would have to be an integral part of our product. So our software minimum viable product (MVP) required that mentors sync their calendars and set their availability. Interested mentees could schedule interviews with them by selecting an available slot from their calendar.

Almost immediately, this led to technical and logistical challenges. Scheduling meetings is a hard problem to solve with pure software – especially for a sole developer that was still a relative noob (me). People needed to cancel or reschedule more often than we had anticipated, and folks have wildly different habits when it comes to managing calendars and scheduling meetings.

We got stuck in the weeds for a while building and maintaining this scheduling feature – handling edge cases, synchronizing with different calendars, handling missed, rescheduled, and double-booked meetings, providing workarounds for folks who wouldn’t give us permission to access their calendars. In retrospect, it was obvious we were over-engineering, but it took us a while to notice. We were putting out a series of fires, moving from one to the next, instead of taking a step back and thinking critically about the bigger picture.

Eventually, with a plethora of issues on our plate and no real growth, we finally asked, “What problem are we actually trying to solve?” We want to help people kick-start their data science careers with the help from experienced mentors. Was building and maintaining software for scheduling meetings really solving that problem?

The answer was no. We had gotten distracted solving a sub-problem of the larger goal. A problem, it turns out, we could leave unsolved. We had been forcing our users to adopt our opinionated method of scheduling meetings – but everyone has their own methods, be it tools like Calendly or MeetingBird, or just a few suggestions over email. We should let them keep that flexibility.

With this high level view, other assumptions became apparent. We were requiring a remote interview for every potential mentor/mentee pair. Yes, a face-to-face meeting is necessary to judge compatibility, but a lot of time can be saved with a few asynchronous, back-and-forth messages. If two people are not compatible for a mentorship, they can often tell it from a few messages. There’s no need to waste the time and headache of scheduling an interview for those cases.

With this fresh outlook, we scrapped the scheduling software completely and and built a very simple messaging platform. It wasn’t pretty. There was not a single bell or whistle (MVP, baby!) but it let mentors and mentees communicate via text without the need to schedule an interview. If it seemed like a good fit, they were free to use their own approaches for scheduling meetings.

All of a sudden, there were less fires to put out. Mentors were still interviewing potential mentees despite us not having our own software to enable it. Because we (eventually) took that step back to ask, “Are we building the right thing?” we were able to recognize our mistakes and focus on building tools to improve the matching process and make our mentors more effective. We could focus on building the right thing. Though, one should never take that for granted!