Road to Product Enlightenment: Learning by Doing

Photograph by Emma Li on Pexels

A curiosity to find the ‘why’ behind everything and a quest to develop big picture thinking, is what got me interested into the world of product, as a software engineer.

I wanted to learn why products were designed and built the way they were, who made those decisions and how. I wanted to know about all that went on beyond the engineering team’s involvement in the product development lifecycle.

“There are three creativities: creativity in technology, in product planning, and in marketing. To have any one of these without the others is self defeating in business.”

— Akio Morita, Co-founder of Sony

In my journey to find these answers I turned to books, articles, online courses, and workshops over the past twelve months. Even though I learnt an awful lot through this research, the knowledge gained always felt hollow. All textual and prescriptive—nothing tangible.

I figured the best way to allay that feeling was to get my hands dirty — to learn by doing. And, PMDojo’s Product Accelerator happened to be just the right fit for this—a 10-week part-time apprenticeship-style program to empower me with real world experience in building a zero to one product.

I have been on the path to learning product basics since almost an year, and now would be what I call the most exciting and fulfilling time for me — our product just went live!

At nine weeks into the Product Accelerator, my team and I have just launched our product Letsconnect — do check it out and let us know what you think at

Going from zero to one in such a short span of time would not have been possible without my incredible product partners — Yanet and Anurag, and all our phenomenal PMDojo mentors. Our unique experiences and diversity of thought combined with a constant can-do attitude, made building together a treat!

In the Problem Space

We began our problem discovery with a crude initial thought on a challenge that we thought everyone struggled with. Not always the best way to find problems worth solving, but definitely a good place to start.

Two people want to meet for coffee. They have two hours on their calendar for this meeting, which includes the commute to and from the meeting venue. Where should they meet?

Someplace that serves decent coffee. Someplace which is not very far for both. Someplace which is easy to commute to for both. Someplace which would be open at that hour. Someplace which would take reservations.

Next with the expert guidance of our mentors, we separated our underlying assumptions and biases from the real pain points. And, after learning to appreciate the significance of a well-defined problem space, we framed our problem statement.

Working professionals in urban areas spend a lot of time and energy struggling with multiple tools to find cafes and eateries suitable for personal and professional meetings.

We still weren't where our mentors wanted us to be or where the start of a great product needed to be. A lot many bits were abstract in our statement. Not only did we need to quantify them, we also needed to validate the claims made in the statement. Moreover, our problem statement wasn't as aspirational and lacked vision. We needed it to embody a greenfield and encourage blue sky thinking.

It all makes sense now in hindsight, but back when we got that feedback we were stupefied. Nevertheless, like true-blue product managers, we embraced the ambiguity and moved forward.

We conducted research surveys to validate our problem statement and extensive user interviews to understand our target audience. We drafted our potential user personas and started to empathize with them. We also charted out user journey maps to further explore the problem space.

And, we ultimately arrived at our problem definition.

We want working professionals to be able to seamlessly find places which are suitable for their professional meetings while accommodating the needs of attendees, without spending time on multiple apps.

And with this, we made it to the other side of the problem space — ready to take the leap into the solution space.

Thoughts & Learnings

My biggest challenge when exploring the product space was to remain within the boundaries of the product space. This was particularly because my engineer’s brain is accustomed to jumping straight to devising solutions when faced with a problem.

Additionally, I also found navigating the traps of confirmation bias extremely interesting in the problem space. This was especially challenging when working on surveys and user interviews, from designing to conducting and later analyzing insights.

A few mindset shifts that helped me in the problem space were —

  1. Not every problem is worth solving : Accepting that the problems faced by me or a few of my contacts might not be a problem faced by everyone — by validating the problem and gauging its desirability early on
  2. Solve the problem, not the symptom : Exploring the depths of problem to completely understand the root cause(s), before starting to solve it — by asking recurring “why?” questions and reaching its core
  3. Optimizing for all is no optimization at all : Bounding the target user segment and focusing on identifying the patterns in their pain points and needs, instead of trying to solve for everyone — by defining a few guiding user personas and empathizing with them
  4. Usability and feasibility belong to the problem space : Thinking about the usability and feasibility of any potential solution, without digressing too much towards ideas for a solution—by understanding all constraints of the problem as well as the target users

In the Solution Space

After the first five weeks, armed with a solid problem statement and overflowing with creativity, we began exploring the solution space.

We studied existing solutions in similar and adjacent problem spaces. We analyzed the competitive landscape for our product. And, we got inspired.

We brainstormed with How Might We questions and were thrilled by the sheer volume of ideas we generated while at it.

How Might We make finding convenient meeting locations seamless?

How Might We accommodate all the needs of attendees in the search for meeting locations?

How Might We make the search process quick and easy?

In that euphoria we wanted to boil the ocean — build it all, in state-of-the-art style, right away. Here designing our early concept with pen and paper sobered us up. And, we learnt to appreciate the feasibility and scale of our ideas and got the first taste of feature prioritization for our MVP.

And, that paved our way towards prototyping our solution and building our wireframes. At this stage we involved our target users again in conducting rapid usability tests on our wireframes.

To our disappointed, we learnt that we were not where we should have been with our wireframe design. We had complicated the search experience a bit too much with our intended user flows. Our user interface was too busy and confusing. We needed to simplify our designs to make the experience more intuitive.

With the feedback from our mentors as well as the insights from our usability tests, we learnt the art of detachment and ruthlessly got rid of all design elements that we believed were contributing to clutter and chaos.

Thoroughly immersing ourselves into the solution space and empathetically engaging with our potential users helped us gain the clarity needed to define the value proposition for our product.

Finding places to meet made quick and easy.

Letsconnect makes it radically easy to search for venues to meet others, that’s convenient for all guests. No more plans with venues TBD.

In a few simple clicks, you can collect guest preferences, run a quick search, find a convenient venue, make a reservation, and notify your guests.

Next, we formalized our goals and plan for our MVP in a lean product requirements document and developed our go-to-market strategy.

Now, with our crisp and clear shared product vision, it was time to get our hands dirty with the actual build. As we were building on a no-code platform, we had to pivot our designs and improvise our feature implementations quiet a bit, owing to the platform’s limitations. To our favor, my software engineering skills came in quite handy here and we were able to navigate this stretch easily and build our MVP by week eight.

Finally, we went live and launched our MVP this week — Letsconnect — do check it out and let us know what you think at

Thoughts & Learnings

One thing I struggled with when navigating the solution space was to identify how to differentiate our product while keeping it intuitive for our users. While using familiar user interface and experience design across products can make a product intuitive, if not done right it can also take away a product’s originality. And, I knew finding the right balance here would be critical to our product’s success.

Furthermore, I found restraining myself from getting emotionally invested into our ideas and designs rather difficult. Tackling it has been quite a spiritual journey. I have only been able to achieve that to a small extent so far, and I must say that I’m already enjoying the fruits of that practice.

A few guiding principles that helped me in the solution space were —

  1. Be scrappy, not hacky : Improvising what goes on under the hood of the product when needed, without compromising the elegance of the solution from the user’s perspective—by prioritizing user experience design over technical implementation when building the MVP
  2. Test fast to fail fast : Iterating through multiple rounds of usability tests with the product prototype to uncover blind spots early on — by leveraging the principles of rapid prototyping to refine the product design
  3. How many features you release vs. how many features you kill : Minimizing resources spent on features that will be eventually killed by deprioritizing unnecessary features — by prioritizing features that address the biggest pain point over features that are mere bells and whistles
  4. Sell the problem, not the product : Using the problem to empathetically connect with target users and letting that lead them to the solution — by owning the key messaging for the product launch and other marketing campaigns

Now, with the MVP launched, we are onto tackling our next challenge which is to promote our product and boost its adoption.

Beyond Launch

I took the plunge into the Product Accelerator hoping that building one product would help me find the answers to all my product-related questions once and for all. Little did I know then that the richness of this experience would only open doors to many more questions across a range of depth and breadth.

This has been a truly humbling experience — I thought I was diving deep into the waters of product, only to later find out that I have only gotten my feet wet so far.

Going forward, I hope to stay curious and continue learning more and more about product. And, at the same time use the fresh perspectives and knowledge gained through this experience to elevate my future interactions and collaborations with our product teams at work.

If you are interested in product, and believe in learning by doing, then do checkout PMDojo’s Product Accelerator.

And, if you’d like to get connected with me, then please feel free to drop me a note here!

Learning to write. Writing to learn.