Product experts share actionable insights from their years of product management. Find useful tips on different ways to structure a product team within an organization, communication amongst different stakeholders, and hiring PMs. Practical advice on beta testing and prioritization strategies will also be covered towards the end of this piece so do read to the end to absorb the learnings from top PMs in the region.
This contribution was authored by Gwen Sim, Senior Analyst; and Vanessa Ho, Analyst, at Quest Ventures, with editing by Yiping Goh, Partner at Quest Ventures.
Product Office Hours is a first-of-its-kind panel discussion and mentorship breakout sessions dedicated to product management. Moderated by Yiping Goh, Partner at Quest Ventures, the panel saw a distinguished panel of product gurus: Shiyan Koh (Hustle Fund), Christine Sou (Wise, Women in Product), Jingshen Ng (M17), and Nan (a fast-growing e-commerce company), discussing in-depth the key topics of Product Management. Forty-three Southeast Asian startups were also selected to have closed-door mentoring sessions with over 15 experienced mentors hailing from Facebook, Grab, Gojek, Lazada, Zendesk, SEA, and more.
This article highlights eight key insights we gleaned from the session.
1. Product teams as a department and part of a scrum team
One of the most common product questions among founders as their startups scale is how to structure a product team within the company. Should the product team be part of the engineering team? Or should they be a standalone department?
The common consensus among product experts is for companies to build a product team as a standalone department once the company has resources to hire for specific roles. While product and engineering teams are typically in separate departments, companies may find it useful to split them up by scrum teams on a project-by-project basis. One method is to group PMs, project managers, designers, and engineers into scrum teams. This helps to move things forward quickly, as they are hyper-focused on a single task, and there is better communication within each scrum team.
For more mature and larger organizations, departments could be split by their mission to discover and deliver. A standalone product team will be in charge of discovering the “what” and the “why” of the product, while the engineering and project management teams will be in charge of delivering the “how” and the “when.” This structure allows everyone in the product team to have a holistic overview of the product and concentrated resources in consumer research and analysis. However, this method needs to be complemented with a robust communication system to ensure that both teams are able to work with one another to achieve the target business outcomes.
Regional product teams face a different set of challenges. Giving autonomy and trust to the product teams in each region while having a unified goal across the globe provides local teams with a good balance of direction and flexibility to carry out their projects. The business metric to focus on across teams depends on the company’s core business, ranging from revenue and volume of transactions to retention rates. Some companies have local product teams down to each country, giving them the decision-making power to include or remove certain features to localize the product accordingly. The key to managing regional product teams is to have clear direction from the global HQ while giving local product teams the ability to make decisions as they deem fit.
Whichever method is deployed to structure product teams, communication is essential to ensure smooth operations and reduce conflicts between teams.
2. Communication is key
The phrase “communication is key” is used in many contexts, and it is especially important internally in the product team, as well as externally with other stakeholders. From imparting knowledge within the product team, to sharing updates to the wider organization, having good communication systems in place is a key lubricant to a well-oiled machine.
As a manager of a product team, sharing skills, expertise, and information should be part and parcel of the day-to-day activities. In terms of sharing “how-to” hard skills, one way is to implement a buddy system for new PMs in the team. Newcomers will then have a go-to person when in doubt of how to use certain tools and systems. This gets them up to speed quickly, compared to them having to follow an internal SOP without senior guidance.
The fine art of articulating the intangible
Softer skills that are based on intuition trained over time are universally agreed to be hard to impart. Having empathy for users and determining the “smoothness” of a user experience can be difficult to explain in words. Oftentimes PMs end up exclaiming “the experience is just not smooth.” One suggestion to tackle this issue is to conduct competitor and user studies. Jot down what feels good and bad about using their product and share it with the wider team. Use those insights to form hypotheses about what customers might feel about your own product and validate them by observing users, collecting data, and having customer interviews. Another exercise to pinpoint aspects of the product to improve on is to get the product team to put on an anti-fan hat and list down everything that is bad about the product. It is an exercise for everyone to explain and prioritize what to work on within the product team.
Documentation, documentation, documentation
To manage turnover, good documentation is a key component of any PM’s role. This exercise is often neglected and deemed as a lower priority in a PM’s to-do list. To ensure that the team does proper documentation, the management team can consider setting up surprise spot checks to keep PMs motivated to document regularly. Managers of product teams can also task documentation to specific people and allow them to allocate significant portions of their time to do documentation. The logic is straightforward; If the management prioritizes it, members will naturally treat documentation with significant weight.
Tighten cross-functional communication
Getting a well-oiled machine up and running cannot be complete without communication outside of the product team as well. Having regular meetings with upper management, the engineering team, as well as other cross-functional departments is a method that fosters team spirit, and unites the organization with a common goal. Tapping on human psychology, individuals feel good about themselves when efforts are made to involve them in changes in the product. Regular meetings are also a good time to gather feedback from different teams with other points of view, to ensure that the product changes are effective and useful. For product and engineering teams who naturally work closely with one another, friction may easily arise when there is a lack of communication. To reduce that, the product team should consider inviting the engineering folks to product meetings from time to time. Both teams will then have an opportunity to share their opinions and build empathy for one another.
3. Product managers do not have to come from technical backgrounds
Having gone through grueling interviews themselves, the PM mentors shared key traits that make someone a good PM, and what they look out for when hiring one.
Ability and willingness to learn new things
The hotly debated question on whether a PM needs to have a technical background or not was answered during Product Office Hours. The unanimous answer is: One does not need to have a computer science degree but he/she has to be willing to learn on the job. As non-technical PMs, mentors shared their journey of becoming a PM without a CS degree and the abundance of non-technical PMs in the industry too. While it is useful to know how systems work and talk to one another, the technical side of a PM’s job can be learned on the go. The focus when looking to hire a new PM is the willingness to pick up things on the job itself. Having immense curiosity and an appetite for constant learning are more crucial to excelling as a PM, not the computer science degree.
Ability to communicate
As shared in the previous section, communication as a PM is crucial to excelling at the role, and hence the ability to articulate thoughts clearly is a huge factor that senior PMs look out for when hiring. The ability to explain intangibles such as the smoothness of user experience would be a huge plus for hiring managers. During the panel discussion, it was agreed that PMs need to be comfortable talking with data and with people. Most people are good at one but PMs straddle in between both realms and being good at both is a key trait to look out for.
Ability to prioritize and execute
A highly-valued PM is one who has a clear and logical thought process and the ability to strategize. With many permutations to work with, PMs often face the challenge of deciding which problem to solve, or which feature to implement first. Having the ability to structure thoughts and reach a logical conclusion of which to prioritize is key to becoming an efficient PM. This comes hand in hand with the ability to execute the intended strategy and ties back to the last point on communication. PMs must be able to work with developers and relevant stakeholders to see through conceptualization stages all the way to product launches and features released.
It might be difficult to suss out whether a candidate has the above capabilities during an interview but here are some ways to assess a potential PM hire. Case studies are a great way to assess the way a candidate structures his/her thoughts. The case study context can change from time to time, from designing a payments system to designing a calendar booking system, so that candidates cannot anticipate the question and are unable to prepare fully beforehand. This will help reveal their natural thought process. Whether the candidate jumps straight into the architecture or asks to clarify metrics can be an indicator of whether he/she is able to structure their thoughts well.
Other common questions to evaluate the suitability of a candidate could be relating to their methods of conflict resolution. Case studies can be used in this context as well. For young startups looking to hire PMs, asking them to share past experiences of having flexibility and agility to adapt to constantly changing environments is also an important question to ask, to make sure they have that mindset to take on the challenges of a growing business. For later-stage companies, questions around being able to focus on achieving business objectives will be more relevant, and that requires a whole different set of attributes and attitudes altogether.
4. Useful metrics to use in product management
To make sure business goals are met in a quantifiable way, deciding on metrics is pertinent in product management. For most if not all businesses, the overarching goal is to deliver value to customers. From there, the company would have to decide on a metric that will measure the success of delivering value, which differs from company to company. It can range from retention rates for SaaS platforms, to engagement rates for social platforms. For established businesses, it is best to have one overarching metric that is tracked company-wide, and have sub metrics for each product line to focus on.
It is relatively easy to decide on metrics to track when the company (or the business model) has been around long enough to understand what customers want. For example, e-commerce businesses are all about transactions. It can be distilled clearly down to quantity, quality, and efficiency of transactions. Quantity of transactions is typically tracked using GMV, quality of transactions, measuring how delightful the user experience is for customers, can be tracked using bounce rates.
The efficiency of transactions, measuring resources needed to invest to obtain quantity while delivering quality, can be measured using click-through rates of ads. For smaller businesses, however, who are trying to steer through uncharted waters, such standard metrics and best practices have not been established. For young startups who are still finding a product-market fit, the useful metric would be the one that validates that the definition of the problem is accurate. When the startups find that customers keep coming to a certain page on the website or a product, the focus should be on finding out exactly why.
5. Beta testing 101
Now that the product has been released for user testing, what data should be collected? When should the team stop testing and work on the feedback gathered?
Both quantitative and qualitative are important during the user testing process. At the initial stage, having face-to-face interviews and understanding the target group is key to finding out how to improve. Clearly segment the target audience for interviews and during the feedback session, ask about their experience instead of brainstorming with them for ideas. Leading questions should be carefully avoided and keep an open mind while listening to their experience. Quantitative data should be collected as the user tests the product, as well as through a post-test survey.
There are a couple of indicators that signal when to stop beta testing and fully launch the product. First is when the company receives many customer calls trying to get access to the product after hearing from their peers. That shows the company has reached a level of product-market fit and could be ready to officially launch. Second is when metrics that were set and monitored have stabilized and reached the goal of beta testing. When users are comfortable with the product and are able to attain the value that the company set forth to deliver, it is time to stop beta testing and launch it officially. For very early-stage companies, many often don’t have the luxury to test. They go ahead to launch their Minimum Viable Products (MVPs) and the best feedback comes from traction, funnel tracking, and retention rates.
While beta testing is largely about gathering user feedback and iterating on it, keep in mind that there are times to listen to customers and there are also times to not listen to customers. Some companies may adopt a strategy where growth is product-led and would rather spend the resources educating the users about the product rather than modifying the product to suit mass users.
6. Planning for product launch
Product launch comes with many considerations including timing, market validation, prioritization, risk mitigation, and post-launch preparation.
For early-stage startups with limited bandwidth, companies need to start planning early (usually at least 1 quarter before actual launch). Anything later than that may expose companies to risk where questions are unanswered and issues are not fixed and the train has already left the station.
The best way for a pre-revenue startup to gain market validation for a product is to talk to people and engage with customers and non-target customers to gain insights. Since taking bets on what product to launch can be a shot in the dark (especially when user experience may be compromised) companies should reduce “bets” and validate what the customer actually wants as much as possible so as to mitigate risk and uncertainty. One of the best practices is rolling studies where companies are getting inputs as a continuous process whether it’s via coffee chats or surveys, even as they are working hard to churn out intended features already. It is also important to build a culture of gathering data and doing analytics in the organization. Eventually, this would set the foundation for data instrumentation unique to the company itself to better roll out future products.
When setting expectations for project launch such as when entering a new market, systematically break that down into all the work that has to be done (big streams to small streams to individual components). For each component, identify the level of priority, risk, and estimated effort required. Priority is crucial especially when there is a target date to chase, for example, when competing against other market penetrators. It is important to know the assumptions and potential risks to prevent getting thrown off. Track along the way if these have changed and adjusted accordingly.
Lastly, for a successful product launch, prepare for the post-product launch. Do not focus on the gear required to climb a mountain only, but also the food and supplies required to survive at the peak and climb back down. Do an equal amount of planning for post-launch. Product launch is just the beginning and it’s important to have the full gear for pre- to post- launch. These could be instruments for metrics, visualization of the milestones, and customer support.
7. Prioritization strategy
In a prioritization strategy, PMs should look at the frontiers and the laggards.
To kickstart, the frontiers are OKRs, where it should almost always start from the top. In some companies, these are topline metrics. Senior management should be clear on the current goal and that will set the tone of what they will be doing next. Understandably, even with clear goals, PMs often face the dilemma of pushing out new features to achieve those goals or improving the back-end infrastructure to better support the product in the longer term.
One method to resolve this is to do both simultaneously. If the back-end system has reached a point where an overhaul is more efficient, there is an option to hire a new team (or an outsourced team) to build an entirely new system while the existing development team can work on the new features that can bring growth. Once features are pushed out, the systems can be integrated together.
The second method is to get input from the engineering team. Questions such as, “With technical debt, how far can the team sustain?” as well as, “After sorting out technical debts, can you deliver features more efficiently and bring performance to the next level?” can be quantified. The team can then collectively weigh them against the value of pushing out new features and decide which is of greater priority.
The crux is to figure out at which point will the technical debt really slow everything down, and plan for resources to be poured in when that happens. The third method is to constantly allocate time to sort out technical debt (ballpark figure of 10-20 percent per week). When it accumulates too much, the team can switch gears to spend about 50 percent of the week to sort them out instead.
Laggards are the bottlenecks, which are technically impossible to remove. Going by its definition, when a bottleneck is removed, another bottleneck will be present. Prioritization strategy often involves fixing the bottleneck but sometimes looking at the bigger picture is a lot more helpful. At the end of the day, PMs need to develop product solutions that optimize processes for the entire company, not for a person or a particular product. Picking the right fire to fight that helps the company scale faster and optimizes resources should be a consideration in shaping the prioritization strategy.
8. Managing product roadmap in line with the business goals
Be stubborn about the vision but flexible about the path. In a startup, things are understandably constantly changing but a roadmap that changes as frequently as every month is too much for any team to handle, and could be seen as a red flag. This may reflect that a business goal is not concrete, or the management team has not thought things out thoroughly before sharing the company’s direction with the team.
OKRs should not change that much because many other business units have considerations to be thought about as well. There are secondary metrics or ways to measure that may change more frequently, but it is important for top-level goals to be firm and clear to minimize changes in the product roadmap especially when it is not necessary.
In one of the social media giants, one of the constant OKR is to increase usage time, and they have 200 divisions spun out to achieve this OKR. While the overall business objective remains the same, the product roadmap in each division iterates only when it allows the company to progress closer to the main goal of higher usage time.
What happens then when the business is still in its nascent stage and is in the midst of validating the business model? In this case, it is important to communicate to stakeholders and the team what the company is experimenting with. While the management team may not have a clear vision of the product roadmap, it is essential to be clear about principles and visions and break them down into smaller problems and solutions for each department.
A short two-hour event generated heaps of learnings and advice that would go a long way for PMs in the region. We hope that this helps aspiring and current PMs master their craft and bring the product management community, along with the wider startup ecosystem in Southeast Asia to greater heights. We have our partners at Women in Product, Supermomos, and a rockstar group of product mentors: Alfonso Fiore (HappyFresh), Malobi Banerjee (Grab), Shivani Mukherjee (The Product Tree), Zack Yap (Xfers), Justin Binh Nguyen, Deepika Rudra Murthy (Gojek), Steven Li (Atome), Elaine Truong, Ayush Upadhyay (Zendesk), Valerie Wagoner (Gojek), and Wei Quan Liow (Greenphyto), to thank for coming forward to contribute in growing our product ecosystem.
Stay tuned for similar Quest Community events coming your way.
This post first appeared on TechNode Global.