Build the product feature structurally

Just over a year ago, I started my journey as product manager. This comparatively smaller time period has taught me a lot of things about self-management as well. Prior to this role, I worked mostly on data sets, excel files, sql queries, and python. The role had reached to maturity stage of its lifecycle and it was imminent for me to get into a broader role.

I was exploring certain directions - data science was one of them, which I had explored earlier at one stage of my professional journey. Though fascinating, it was mathematics intensive which wasn’t suitable for me in the long run. The other direction was product role. I was fascinated by slightest of the features focussing on core user problems such as Netflix’s ‘Skip intro’ feature, which brought me to the world of product management.

In my opinion, the world ‘management’ in product management stands for the most underrated part of this job. A lot of people focus on the designs, core problems, metrics, and solutions. But behind all these components, there are actual humans either consuming or producing something. Ultimately, one has to deal with human beings irrespective of what does these component on surface mean. The various human stakeholders from product manager’s point of view include:

  • Users
  • Business Owners
  • UI/UX Designers
  • Developers
  • Marketers
  • Operation Managers
  • Customer Care Executives
  • Product support
  • and more

The stakeholders comes into picture generally in this order when you are in the product discovery and development phase. The timelines are important. In an agile development, you are shipping features every 2 weeks (or whatever your sprint length is).

Getting all the stakeholders aligned around the sprints is more of an art than it is science. Since, not all stakeholders follow the agile development methodology except developers, designers, and product managers. A general rule of thumb to structure your product development lies in the timelines of actual development of the product (when developers are actually coding it). Taking the date(or week) as the benchmark, your requirement gathering and problem identification phase should be running 2 sprints ahead of actual development sprint and design sprint should be at least1 sprint ahead of development sprint. In this way, it’s easier to gather requirement and feedback with deeper understanding so that you can communicate the problem to UX designers to work on them who in turn go through the design thinking, user feedback, or design reviews etc. It’ good to keep some buffer with design sprint.

One of the simplest way to approach to the solution
One of the simplest way to approach to the solution

Easier said than done, the requirements could show up for product managers few days before the actual development sprint starts and then, you are thrown off the schedule you had decided for yourself. Even the option of delaying is sometimes not a feasible one in critical scenarios. The best way I see to handle these kind of situations is to get as much as clarity from the stakeholder who has posted the requirement and spend less time in requirement gathering (because you don’t have enough time anyway). And, minimise the involvement of designers as much as you can. This works well when requirement mostly deals with modifications in previously developed feature rather than developing a completely new feature. It’s always helpful to learn a bit of basic designing. (Figma is easy to start with)

Once, you have understood the problem statement, gathered the requirements, prepared the designs, and clearly defined the solution, you are good to go for sprint refinement session where you will be discussing the problem statement and solutions with the engineers. There is still a chance to come across the questions or sometimes, road blockers around technical implementations of the solution but with good preparation, it becomes easier to face or handle them.

For next sprint, Repeat.

— “The best way to fight is to prepare in the best way.”

Learning indefinitely