Background
In 2021, I left my job at Visa Inc. as a developer and joined a smaller company based in Singapore. It was my first job as a Product Manager, a role in which I had a genuine interest and hoped to build a career around. The company operates a FnB business and employs a small development team intending to tackle the business's challenges and, if successful, intended to offer the software solution to the broader market.
Lay of the Land
When I joined the team, the development team was already working on proof of concept POS system. It was meant to be an interim solution for us to temporarily address the scalability limitation of a legacy POS system and extend the useful life of the existing Windows POS machine. The team encountered a few issues because the requirements were unclear and the developers were simply mandated to deliver a POS system with similar functionality. This resulted in many requirements mismatch because the system developed was not identical and communications with the business stakeholders were not established. It took me and the team approximately 4-5 months to close the gap between what was required and what was being developed before we could go-live. We were still facing several issues that we could not immediately address for our users because the system was built on top of an open-source ERP system. That imposes many UX restrictions for our users because out-of-the-box components were used. Any UX customization required is tedious and slows down the team’s ability to deliver features that could promptly tackle business challenges.
Thoughts: As an employee, we often would hope to enter a company where things are well-organized and well maintained so that we could assist us in learning the ropes and then subsequently perform well in our respective roles. Unfortunately, the reality is often quite the opposite especially in smaller companies or start-ups where processes are not clearly defined. It also hinges on the management’s priority to set the right process in place in order for the organization/team to function optimally. This was very much lacking in the company because the way in managing a software team is vastly different from managing a Food and Beverage operation team. Having realized that this gap in the organization and coupled with the urgent need for me to hone my product management skillsets, it became apparent that I would first need to improve on the internal process within the Technology team. This was only possible because of my prior experience working in Visa where I was exposed to more mature Software Development Lifecycle practices.
Organizational Goals
With the window-based POS system being rolled out, stabilized and the most teething user needs addressed, it is now time to chart the next phase of the product roadmap. These days, technology has increased productivity in eateries either by delivering the same output with fewer resources or delivering more output with the same resources. The picture below illustrates just how transaction acceptances have morphed from simply having a cashier.
When a customer enters a restaurant, he/she only has a goal and that is to consume food and drinks. An idealistic scenario would be one where a customer can enter a restaurant, get seated at an empty table, have the food that he/she wants to be served, consume the food, and be able to leave the premises with payment automatically settled without lifting a finger. The technologies required to build this customer experience are likely available, however, the investment to bring this to life is not going to be cheap and the investment risks are high. That’s when the role of a product manager comes into play. To be the main driver in deciding the most pressing issues to tackle, with the finite available resources, to yield the highest return on investment.
The Problem
As I begin to understand the management’s business directions, the competitive landscape, and the current state of our system. It became clear to me that the proof of concept POS that we have just completed is not going to serve us well in the long run. Given that this is not a technical blog, I will not be going into the technical details and the decisions on why Odoo does not work for us. For us to be able to explore new solutions, the core POS system needs to be comprehensive and extensible. The POS is also not something we can discard in the current FnB operations as a huge group of our primary customers still transact in cash. We also wanted a system that could be transitioned into Software as a Service, allowing us to break into the market and open up a new revenue stream for the company. With this new alignment, I began the journey with my team to build my first 0 - 1 product, a revamp of the POS system.
User Persona
The current POS served as our Minimum Viable Product(MVP) and we knew who our end-users were. We created user persona profiles because it allows everyone in the team to understand who we are serving. This information came in handy especially when we are deep into the development of our products. When making complex decisions, user persona helps lift us out of tunnel vision to ensure the features built ultimately serve their needs.
While rolling out the POS, we were able to rapidly gather feedback directly from our users. We conducted usability testing with the different groups of users/stakeholders to understand what they love or hate. It helps us identify good features to retain so that more emphasis can be placed on problems that users found are important but existing solutions are not solving satisfactorily. Chapter 4 of The Lean Product Playbook mentioned in detail the Importance vs. Satisfaction Framework if you would like to learn more about this topic.
User Stories
Through the exercise, we were able to gradually transform the information gathered in User Stories for each group of user persona. As our objective is no longer to deliver a MVP but a Minimum Delightful Product(MDP), the number of user stories in this project was huge (you guessed it, Waterfall!). My team trial-and-error multiple tools(Onenote, Confluence, Jira) and we eventually decided that the best way to manage User Stories is to write them directly in Jira, even if you are just working on the first draft.
Thoughts: We tried Onenote and Confluence because it allows multiple team members to collaborate on the same document and provides a single source of truth. However, writing it and refining it on Onenote means that we will have to manually import the stories into Jira. Confluence has a nice feature to bulk create stories on Jira, but the confluence page that we were working on eventually reached its limit(we had more than 100 stories) and it was close to impossible to update the page further. Writing and refining the user stories on Jira still provides us with a single source of truth and our development team can start sprint planning almost immediately once the details of the user stories have been finalized. There is also no need administrative overhead to update the user stories at multiple places in case of any requirement changes(which happens all the time). It is also possible to embed these user stories back into confluence which was a huge lifesaver! That’s because you can access the information easily from a single confluence page(for proof reading) and it can also be subsequently reuse for our Product Requirement Document to obtain sign-off from our business stakeholders.
Low Fidelity Mockups
As we continue to refine the User Stories, our UIUX designer works along side us to build wireframes(or lo-fi) of the product with information from the user stories. We found that enabled us to better visualize our product and to facilitate discussions and increases the level of details in the user stories. High quality user stories reduces ambiguity when development starts and drastically reduce the requirement clarifications between the Product and Development teams. Given that POS systems are used everywhere, we also conduct competitive analysis at this point to understand the market trends and what competitors are doing both good and bad. It serves as additional data points for us to craft our own product.
Once the first draft of the wireframe is ready, we proceed to:
Schedule design discussions with the Development Team
Getting Feedbacks from users with Low Fidelity Mockups
Design Discussions
The reason for running design discussion with the Development Team is because we believe best ideas comes from everyone in the team. We had put this in practice and it gave everyone a sense of ownership and an opportunity to steer the product outcome. From my experience, when people are given an avenue to share different perspectives (product team focuses on experience, development team focuses on technical feasibility), the resulting feature can tackle the problem better than what each individual can come up with. Design discussion with the development team also let the developers evaluate the complexity of building the experience that the product team desires. A developer from my team shared this video on How UI/UX can break the backend and it justifies just how critical it is to have the development team be involved early in the design of a software. A simple push notification implementation and have massive repercussions when it comes to implementation. This was process was also missing back when I was a developer in Visa and it led to a lot of inefficiencies and friction developing products.
Getting Feedbacks with Low Fidelity Mockups
During the development of the previous POS system, the team learned through the hard way of delivering features that did not fulfil users’ needs. We were determined not to repeat the same mistake and started our feedback look as soon as our lo-fi mockups were ready. Coupled with the use of UX research platforms like Useberry, we were able to let our users experience how the end product will feel even before a single line of code is written.
The feedbacks reduces our risk of delivering features that does not meet user’s expectations. This is highly desirable in any organizations because the end-product have a higher chance of achieving product-market fit and potentially increasing the ROI of maintaining a software team.
High Fidelity Mockups
After going through a few design discussions, the lo-fi and User Stories will be sufficiently groomed. That is when our designer can start building the High Fidelity mockups. Our designer had the autonomy to design the POS and the backend portal UI down to the components level. However, we soon realized that the effort to develop custom components were very high. This was not exactly a good use of our developer resources because there were free open source responsive components such as Mantine UI and there is really no need to reinvent the wheel. If we could turn back time, we would use the Mantine library to assist us in designing the Hi-Fi.
Hand over User Stories to Dev Team
Concurrently, the product team will also hand over the Jira Board to the Engineering Manager. This is when he/she can begin reviewing the scope of the project, plan the task assignment and project timeline. My role as PM do not end here. To a layman, one might think that the design discussion would have helped iron out 99% of the details but the reality is far from it. As developers get assigned their respective tickets and the sprint starts for them to carry out development, they start to go into the implementation details. The myriad of blockers they face is endless and my job is to assist them and understand the possible solutions and its associated impact of each decision. These gaps are simply impossible to foresee even with my experience as a developer and it takes multiple discussions consistently to gradually achieve what we set out to do.
"Quality is never an accident; it is always the result of high intention, sincere effort, intelligent direction and skillful execution; it represents the wise choice of many alternatives."By a wise man
Quality Assurance
From my working experience, having a QA team is always a luxury. Typically, only larger organizations have the financial resources to maintain a QA team, as such, developers are often required to also hold the responsibility of testing the software(example: unit testing). Fortunately, we have a dedicated QA engineer whom we worked with to agree on the Acceptance Criteria of each user story. He support us by manual testing the completed user stories in each sprint, and the product team takes over the ticket to conduct our User Acceptance Testing(UAT). Given that the product is not yet live, we are only able to conduct UAT on behalf of the users after the system has been sufficient developed to support certain user flows in the staging environment.
In my opinion, this UAT process is not ideal because the end-users approach towards interacting with the software is very different from the ones who built it. To reduce our risk, we selected a few stores which has low traffic flow to conduct a soft launch of our new POS. This will provide a more thorough and accurate end-user testing of the software and give us time to make tweaks and conduct bugfixes if required.
Summary
This article was meant to pen down my first experience building 0-1 product as a product manager. I do not claim to be an expert and there is still much to learn from this craft. To any aspiring PMs reading this, I hope my experience gave you a glimse of the fun and not so fun aspect of the role. It took me many months of learning/preparation/interviews before I finally broke into Product Management, so if you are not there yet, be patient! Persevere and your time will come, good luck.
Comentarios