Aced Communication 💬
As a Product Owner, I am like an octopus working with multiple departments - engineering, customer service, marketing, you name it. To ensure work efficiency, transparent communication is vital. In the following, I’ll share the MEET framework I adopted to facilitate communication.
Manage Scrum Team & Product Roadmap
To build and iterate things fast, we ran Scrum methodology with the engineers. As a Scrum Master, I ensured the productivity of each meeting, delivered projects on time and assisted my manager to do resource planning.
​
To ensure discussions were constructive, we conducted 8 different types of meetings with the engineers. Below is the summary:
For resource planning, we first made a roadmap to show the engineers the amount of work we needed to do and the limited resources we had so as to get their buy-in for getting more engineers to the team. These were the steps we took to formulate the roadmap:
-
We identified which features were “Must-have”, “Should have”, “Good to have” & “Nice to have”.
-
I gave each feature an impact score (with 5 as the maximum score). The impact score was more detailed compared to the one in the prioritisation workshop as we needed an accurate view of the influence of each feature. When formulating the impact score, 5 factors were considered with the following scale:
-
Customer engagement (20%)
-
User experience (20%)
-
Sales funnel (40%)
-
Operational efficiency (15%)
-
Brand awareness (5%)
We calculated the overall score to prioritise the features to be developed first. The bigger the score, the more important it is.
Here's an example:
For the feature of magic link login, these were the scores given to each factor of its overall impact score.
The impact score would be 5x0.2+5x0.2+1x0.4+4x0.15+1x0.05=3.05
3. We shared the roadmap with the Lead Engineer so he could rate each feature in T-shirt sizing (XS, S, M L). We showed him the respective number of days per full-time equivalent (FTE) for reference.
e.g. The engineer gave an "L" for the effort to develop the magic link login. (L=21 FTE, meaning it takes around 21 days for an engineer to create the feature)
​
4. We then added up the grand total of no. of days/ FTE of the "Must-have", "Should-have", "Good-to-have" and "Nice-to-have" features and divided them by the no. of FTE in the Scrum team. The result showed the no. of days needed for the whole team to develop all features. We converted the days into months to see how long it would take to complete those features. This also helped us to assess if we could deploy the features within 3 months (a quarter). We also needed to leave some capacities for fixing bugs.
​
e.g.
It's summarised that the grand total of all the "Must-have" features are 140 in Q3.
​
We got around 3.5 FTE for development. (The "0.5" is equivalent to the time the Lead Engineer could spend on coding by himself)
​
Therefore, the number of days it would take for the team to develop all the "Must-have" features is 140/3.5=40 days.
​
Since there are 22 working days per month, it would take the engineers around 1.82 months to develop all the "Must-have" features.
Engage Actively:
Internal Newsletter
At past, different parties needed to send private messages to the Product Team directly to know the development progress of certain features. The individual and repeated responses could be overwhelming. Therefore, we published the Circle Digital Newsletter biweekly so the major parties knew what was happening. We shared updates on features that have been released, were under development and would soon be developed. Data on monthly active users and key metrics for certain growth features were also shared. We asked the reader for feedback so we understood how to boost the readership of our newsletter.
​
As a result, we successfully reached a 60% open rate among 30+ stakeholders consecutively. We also heard enquires about things we shared in the newsletter from the board. This initiative not only saved us time and effort to share updates but also stirred up awareness and interest in our app across the company.
Express Swiftly:
Slack Broadcast Channel
We received many requests for data enquiry, feature optimization and design adjustment. Nonetheless, our first priority was to develop the function and content for new products. There was limited capacity to work on external requests and the estimated delivery date of the requests would often be altered.
Though the newsletter shared regular updates, it was not able to keep various parties posted promptly. To let different parties understand our constraints and know the change fast, we have opened a #circle-development-update Slack channel where we told different parties about the tasks developed, would be developed and deprioritized. I would update the channel by the end of every Sprint since that’s when we knew how many tasks we could take on in the next Sprint.
Compared to the newsletter, it’s a more timely update on bite-sized features or tasks required by external parties so they could adjust any dependencies accordingly or escalate the request.
Talk Frequently:
Regular Meetings
In a fast-moving environment, the Product Team often received changing requirements and needed to take action fast. To ensure we were on the same page with other departments, we met different stakeholders biweekly. We talked about the progress of cross-team initiatives, updates from both parties and action items. If there was a company-wide project, we would do a kickstart meeting to help everyone understand the purpose of the project, the role & responsibility and the timeline. If the regular meeting involved a larger group, we asked each party to share updates via a one-slide template to ensure meetings were productive and on time. An email would be sent to everyone to summarise the meeting highlights and action steps for record and tracking.
The Digital Product Team also had internal meetings weekly. One of my favourite sessions was Knowledge Sharing. My manager brought in different topics for discussion, like Amazon’s Working Backward Method, Data Analytic 101 & Scientific Product Roadmapping. It inspired us to think about how we could revise the existing ways we developed products in a more user-centric and data-driven manner.
​
Besides, during the weekly 121 meeting with my manager, I would share the progress of my work, the small wins, the blockers, the proposed solution and the work plan for the coming week. It helped me reflect on whether I had spent my time across product discovery & delivery, workflow enhancement and stakeholder communication wisely. Meanwhile, it propelled me to think about how I could solve challenges like backlog priorities or stakeholder conflicts to flex my problem-solving muscles.