5 key takeaways as a Product Manager from 2021
“Challenge norms, push boundaries, don’t fear mistakes and always be open to learning.” — JJ Wilson
When I was onboarded in late 2020, I was given the mandate to build a new user-friendly application that would allow us to kill the legacy application that was being used at that point of time.
The older application was built for our internal teams to help find out and fix the issues being faced by users from a technical standpoint. Slowly, other teams started using this application more and more. Since, this was not the original intent of building it, it was becoming quite cumbersome to maintain the data and to update the application as per the business users’ specifications.
Building a new product to replace an existing one is no small feat. It involves protracted negotiations with all concerned parties as your users are accustomed to a certain way of using the application.
Nevertheless, we did accomplish our goal and were able to bring out the new application in mid-202. The users loved it and thus, allowing us to finally let go of the legacy system.
The eventful ride has been thoroughly enjoyable thus far and I keenly look forward to new learnings apart from the ones outlined below.
Lesson #1: Engage your Target segment in Design and Development — Wireframe helps
Building applications for internal users will be different from building applications for external users. But the essence remains the same and that is to ensure that you reach out to your target segment and involve them from the beginning.
Include your UX designer in these meetings as this helps to convey that you are serious in designing user-focused applications. Another advantage of this process is that during discussions, the designer could quickly grasp the user inputs and help create a UX wireframe that keeps those requirements in focus.
Most people respond to visual stimuli. Therefore, always try to bring a wireframe to the discussion to help them understand what you have in your mind. Presenting only datapoints will just confuse them.
The wireframe need not have all the bells and whistles. It could be a basic wireframe to help convey the concept to the users and to help them to provide inputs regarding what and how they would like to view the information on the application.
Lesson #2: Err towards Over-communication
Management style differs whether it is a new startup or a well-funded startup or an established firm. Irrespective of organization type, the higher-ups would always be interested with the development and deliverable timelines.
And even though the user might not be interested to know the progress, they would always be keen to know the delivery timelines.
Regular review sessions with the users and management helps to ensure that they are aware of any delays. This reduces escalation events to a large extent allowing the focus to remain on the deliverables.
A good practice is to send regular email updates detailing the features and functionalities deployed as part of the release and the target planned for the next release.
Lesson #3: Learn how to say No
Products are typically built not for one specific user, but for a group of users. There will be different set of requirements from various users. We need to strategize the requirements to ensure that they are in line with the vision of the product/solution.
Thus, if there are requirements which do not fit with the overall vision, we need to communicate the same with the users. I utilize the MoSCoW prioritization framework with my users to help them identify which requirements make a better fit to the product scope and which ones are mere embellishments.
Lesson #4: Empathize with your users and team
Customer empathy is required to understand their needs (overt and latent) and pain points. Our target users were pleasantly surprised when we brought our first developed wireframe to them. It really helped kickstart their journey with us.
It is also important to empathize with the team as the members would not be at their peak productivity all at the same time. Every team usually consists of two types of workers: smart workers and hard workers. Both are equally required for a successful delivery.
Usually, the smart workers are the spirit of the team and help make the team a more cohesive unit. The hard workers are typically a quiet lot and are usually considered to be slow with their deliverables. Quite a few times in my career, I have observed that they provide good insights into a deliverable and find out bugs or issues which weren’t considered by anyone.
Lesson #5: Keep your UX designer and Development Team in sync
During the early stages of the development journey, our designer would bring out awesome UX design screens for the UI. But our UI developers would struggle to deliver the same output as shown on the screens.
This scenario typically plays out due to two reasons: Either the UI developers are not experienced enough to bring those screens to life, or the designs could not be developed through existing technology stack defined for the development.
This creates unnecessary friction between the team members and leads to constant trade-off on the design.
To avoid this scenario, it is encouraged to have Design Sprints to ensure that the designs are getting finalized as per the technical strength of the developers and helps push the developers to build upon their technical expertise to help provide amazing user experience.
Hope these learnings also help you in your journey as a Product Manager.
