A Series on Product Management — Part 1: Build minimally, not ideally.

From the perspective of Irfan Alam, Founder & CEO of Frontrow Health, a startup building digital stores for doctors, where patients shop and save on health products their own doctors like best.

I had never been a formal ‘Product Manager’ before starting Frontrow Health, but now after a year+ of full-time managing engineers and designers I thought it’d be helpful to share my mistakes/learnings for anyone interested in getting started with product management.

Today’s lesson is in “MVF” — building a minimally viable feature.

Mistake/Lesson #1: Don’t work with engineers to build a feature ideally, work with them to build it minimally.

My first engineer, Anand (once a PM at Microsoft), taught me this trick (and continues to remind me of it during our weekly sprint planning):

It’s not about whether you should / shouldn’t build something ideally, it’s about when to build it ideally.

Is it worth the extra development effort today to build a feature ideally if you don’t yet have data to support whether users will utilize the feature frequently?

Simple example: We were building a “recently viewed” feature for our doctors’ storefronts because our research found that patients could benefit from an easy way to revisit products they had checked out.

When the design team handed the ticket off to Anand during a Monday sprint planning meeting, he reviewed the requirements and said:

“Sorting the recently viewed products chronologically is a low lift; however, categorizing by date stamps will add at least a day of development effort, which I could instead use to work on pushing out another feature for the upcoming deploy. My recommendation is release this feature without date categorization, but if we track that users frequently use this feature, we can reprioritize accordingly.”

He was right.

Patients knowing when they visited a product (particularly if they visited many over time) was a standard e-commerce feature that our patients also preferred during user research, so our designers rightfully drew it up as such.

However, weighed against other priorities for that specific sprint, it didn’t make the cut for the ‘MVF’.

While seemingly minor (a day of development effort), my product team continues to remind me that every day counts, and we shouldn’t just weigh priority of X feature vs. Y feature during a sprint meeting, we should also carefully assess whether a certain requirement of a feature is equally as necessary.

How we spend our time is just as important as how we spend our money. 🚀