| Company | Role | Skills |
|---|---|---|
| LCBO | Product Manager | Rapid Prototyping |
| Scrum Master | User Interviews | |
| Journey Mapping | ||
| Market Research | ||
| Wireframing |
After noticing a lack in process for effectively handling the lifecycle of a software bug, I took the initiative to create a product that would allow for more transparency and coordination within the LCBO innovation team, and with our stakeholders. Beginning with problem space analysis, I conducted user research to develop personas and customer journeys, ultimately arriving at a functional prototype that was designed with, and for, the end users.
The Liquor Control Board of Ontario (LCBO) is a Canadian Crown corporation responsible for selling and distributing alcoholic beverages across Ontario. With more than 660 retail stores and 450 vendors, the LCBO’s quasi-monopoly status in Canada’s most populous province has made it the world’s largest purchaser of alcoholic beverages. With a lot at stake, the LCBO is dedicated to managing and delivering remarkable experiences to Ontarians for the world’s wines, beers, and spirits.
To stay competitive and avoid complacency despite a quasi-monopoly status, the LCBO kickstarted a new initiative with LCBO|next based out of Communitech, a Waterloo innovation hub. As the innovation lab, it’s responsible for exploring new technologies and enhancing the LCBO’s technology initiatives to solve the unique problems customers or business partners face. This means bringing fresh ideas, creative thinking, and new skills to the table and constantly learning on a day-to-day basis. With the resources of a large company and the culture and energy of a start-up, the LCBO|next lab produces ideas that have lasting impacts on the LCBO’s operations and customer experience across the province.
Co-op students are always encouraged to seek and discover new initiatives that can be tackled. One of the ideas that I came up with was tackling the problem of the lab’s inefficient process for tracking and remediating bugs. This was a brand-new idea with nothing completed by previous students, so it was important to dive right into research.
The LCBO|next lab is always looking for ways to improve existing products to optimize their impact and ultimately improve the return on investment (ROI).
Historically, any bugs for existing LCBO|next products have come through email or phone, typically to the Director of Innovation or the Product Manager Co-op. This was only if the user already knew who to contact, and how to contact them because this information was not made readily available in any of the applications developed before my term. Additionally, any important emails that were directed only to a previous Product Manager Co-op would forever be lost since no one else had access to their inbox.
For LCBO|next applications that were hosted on the LCBO’s production server rather than LCBO|next’s production server, any bug reports or feature requests were submitted to the LCBO’s ServiceNow IT Portal. However, this channel of communication was only sufficient for LCBO employees since an LCBO email was required for accessing the ServiceNow portal.
In order for users to get the most out of LCBO|next products, they needed to be able to use the applications bug-free and suggest improvements to the app that could simplify their workflow. Since users didn’t know who the point of contact was, or how to contact them, lots of constructive feedback for the applications were being missed and users were extracting suboptimal value out of the products. In a typical B2B environment, this could have ultimately led to churn.
As our first course of action, based on what we knew, we listed out some assumptions.
Since this project was occurring during a co-op work term, we faced the ever-present constraint of time. Being confined to a four-month work term, we were determined to at least get a bronze phase of the project out the door before the term ended so that the new co-op students could pick up the project in an easily comprehensible state.
Another constraint was that our team was kept within the confines of our own homes, as millions of others were during the COVID-19 pandemic. This meant we couldn’t conduct in-person user interviews, usability tests, or concierge tests, which could have provided us with some invaluable insights. Hosting these sessions remotely may have also influenced the transparency or accuracy of our results/findings, but we had to make the most out of the cards we were dealt.
Talking to LCBO|next product users was the easy part. We knew who to reach out to, and we could easily access their contact information.
On the other hand, for LCBO|next students, we couldn’t talk to students of the past or future. So, the next best thing we could do to “talk” to previous students was to read any documentation they left behind. Despite its extremely agile nature and speedy tempo, the lab has a culture of documenting almost every aspect of a product journey, so a lot could be learned from just reading.
Other than future and previous LCBO|next students, I would also have to interview the Director of Innovation, the Manager of Innovation Development, the developer co-ops, the designer co-op, and myself. Interviewing the others wouldn’t prove too challenging but seeing as how there was no other product manager to interview, interviewing myself would negate the purpose of having an interview, which is to dispel any biases or false assumptions I may have.
After conducting 8 user interviews, we compiled all our notes and conclusions and created two distinct personas. The personas below are simplified versions of the personas we had developed.
Using a combination of the newly-made personas and the insights we gained from the user interviews, we were able to visualize a typical customer journey and create a journey map. Typically, this would've also been supplemented with findings from an in-person concierge test, but with the ongoing pandemic, we had to make do with what we had.
As with any company, once the Product team had an idea that’s been validated, we had to look into what was already available in the market and decide between buying or building out a solution. Several solutions were considered and analyzed, FreshDesk being one.
FreshDesk is a SaaS cloud-based company that helps customer-facing teams organize, prioritize, and respond to customer queries. Although it is widely accepted by companies in the technology industry, we concluded that it was not right for our needs. For a company to leverage FreshDesk, users must email a designated support email (e.g. support@lcbo.com). Leaving an LCBO|next app to write an email could discourage users from submitting queries, so we wanted to make the experience as seamless as possible and embed the query-submitting functionality directly into all of our LCBO|next apps.
From prior experience, I had learned that integration availability was not as extensive as we would have liked from FreshDesk, so it was not ideal to integrate with our legacy systems. We also wanted to avoid the overhead involved with integrating FreshDesk with each of the several apps we managed regularly. Creating our own application from the ground up would allow us to create it in a way that we could think of it almost as a browser extension we could access from any of our LCBO|next apps. It would also allow us to directly run analytics through Amplitude, Google Analytics, or Segment rather than having to query data from the FreshDesk portal to run analytics separately.
That’s all to say, it was better overall for us to simply build out a solution.
After deciding to build out a solution, since we were working for a Crown corporation, we needed a sponsor on the corporate side who could vouch for the necessity of the project and act as a representative in the HQ tower. Working for a government organization, unfortunately, meant that there would be a multitude of hoops to jump through to get the clearance to commence software development. This would involve multiple departments such as Corporate Communications, Legal, Strategy, etc.
We wanted to first see if the product would be adopted by our target users and if it would prove to be valuable. So, we adjusted our requirements and omitted anything that involved saving sensitive/personal data to skip ahead through the regulatory process. We would cross the bridge of dealing with personal data when building out future phases of our product; only when necessary and when we knew the product would provide value for years to come. We also weren’t trying to build a retail consumer-facing product that dealt with a potentially controversial topic such as underage drinking, so we could skip ahead with getting clearance from Corporate Communications as well.
Finally, I developed a product requirements document (PRD) to present to company executives, and we successfully leveraged the data we collected in our journey to get the go-ahead for the project. In the innovation lab setting, much like any start-up, companies don’t have the time and resources to build out a fancy prototype to show to stakeholders. We were looking for quick wins, and having a low-fidelity wireframe was sufficient in getting the job done.
To ensure internal team alignment, the product designer first put together a low-fidelity prototype and walked through it with our team before moving on to a more sophisticated design. For good measure, we also ran through the low-fidelity prototypes with some helpful potential users. At the lab, we manifested a user-first culture where we would involve our users as frequently as possible, to ensure that we were building the right thing. We recognized that user demands can change with time and more information, so we never hesitated to invite people to get a sneak peek and show improved iterations of our designs and user flow. This worked in our favour as well since we would constantly be receiving feedback and fine-tuning our product.
With all the measures we were taking to ensure we were building out the right product also came the concern of scope creep. Scope creep doesn’t necessarily only occur once software development begins. It can also occur in the design stage, so it was important for us to be mindful of features or capabilities we were adding through frameworks such as the RICE scoring method.
There are two users for this project: LCBO|next employees and LCBO|next app users. The goal is for the user of any LCBO|next product to be able to submit a bug, suggestion, or provide general feedback to the LCBO|next team. On the LCBO|next side, the goal is for the incoming structured data to be logged in a system that persists beyond co-op terms, and allows for direct communication back to the submitter.
For the app user side of the portal, it was designed to be a modal window that activated in any LCBO|next app upon clicking the always-visible but discreet “Help” logo, which is a chat bubble in LCBO green with a friendly smile. In addition to the ability to input relevant information depending on the type of request, the portal prompts users for their email if they desire to be notified of the date they can expect their request to be addressed.
For the LCBO|next team side of the portal, it displayed incoming requests, which could be categorized and filtered by type, urgency, recency, and product. If the submitter opted to provide their email, a chat window would be enabled for the ticket, which would appear to the user as incoming emails. This would allow any current or future LCBO|next employee to view the details and communication that occurred for any request, active or closed.
Overall, my experience at the LCBO was beyond valuable. In four short months, I was fortunate enough to learn about and facilitate the product development process, leading a team of developers and a designer. Through this, I truly believe I hit my stride as a product manager and developed confidence in my abilities, which is priceless in such an ambiguous field as product management.
I was fortunate enough to have an amazing supervisor in Danny Ho, the Director of Innovation, who supported me the whole way and was always open to answer any questions that I had.
"Nick was an exceptional Product Manager on the LCBO Innovation team and helped shape the direction of multiple high-impact software products used by LCBO's agency and grocery partners.
He is very curious and detail oriented, and was very adept to understand business’ needs and tradeoffs in deciding product scope, roadmap, and delivery timelines that were ambitious yet feasible.
Nick is a natural at engaging designers, developers, and stakeholders, and was specifically praised by our business partners for a job well done. If you’re looking for a product manager or someone who can get projects delivered, don't hesitate to reach out to Nick!"
