A great product is a synthesis of technology and business thinking. How do we decide what goes into the product and determine the roadmap of the product? How do we establish the balance between the business and technology of the product? In this post, we discuss some interesting lessons learned on product management and why both business leaders and technologists don’t get it.
“New is easy, but right is hard.”
– Craig Federighi (Head of iOS & Mac OS X, Apple)
Product Management in a Nutshell
Traditionally, product management is a function within the company where a product manager focus on the following objectives: (a) planning the business strategy and analysing the market segmentation, risks and competition out there, (b) figure out the product roadmap and interface with the engineering lead and team to deliver based on the timeline and milestones set, (c) collate customer feedback, both qualitative and quantitative and find ways to build up customer base, (d) figure out the marketing plan using different channels, (e) manage the financials with profit and loss (P&L) and (f) collaborated with cross-functional teams to execute on the product. Of course, if a product does not work out, the product manager can choose to close down the product. Whether it’s a startup or a corporation, a product manager takes responsibility on the success or failure of the product. In a startup during the early stage where it’s just a two to ten men team, the CEO is typically the product manager. In my case, during my tenure as a CTO of the startup, my role was closer to a product manager than an engineering leader, because on top of architecting the platform and planning the product, I have to do the strategic partnerships with 3rd party developers and web publishers, pre or post sales follow up, and collaborated with the business teams to achieve the targets for our company.
In modern day, product managers are no longer limited to someone with a business background. If you examine the interesting technology companies such as Amazon, Facebook or Google in the US (and not in Asia), some product managers rose from the engineering leadership or the companies prefer hiring engineers to be product managers. Having an engineering or scientific background offered some advantages but yet at the same time, it does not mean that the engineering person can rest on the laurels. Like the business person, the engineering type product managers have to break through a steep learning curve and understand basic business fundamentals. The danger is that the engineering type product managers dismiss basic business concepts and do not move away from a technology centricity to a user centricity role.
There exist a chasm between business and technology/engineering leaders. In the world of the business person without any understanding of how things are built and made, they start with the following line of thinking: (a) customers gave feedback that they need X features, (b) determine whether it should be easy to build them without consulting the engineering team and of course, they usually miss out the obvious test cases that might lead the user to unintended consequences and (c) they want the features to be built by tomorrow and of course, they are being pushed back with resistance from engineering teams who would begrudgingly obliged to entertain their request but got their timelines and milestones totally screwed. On the other side, the engineering leader also make a similar set of mistakes: (a) they have the mentality that we built and customers will come, and insist that marketing is a waste of time, (b) insist on technology centricity by being fixed towards certain choice of software without thinking about the constraints of the problem and (c) they do not negotiate with the business owners and I have seen this happening a lot more in Asia where technology teams are just being rolled over by the business teams without pushing back, and in the end, got themselves screwed.
Of course, how do we determine between good and bad product managers? Ben Horowitz, co-founder of the famous venture capital firm, Andressen Horowitz, offered a good essay entitled “Good Product Manager/Bad Product Manager” which gave probably the best answer to how we should measure ourselves to be good product managers.
How do we decide the product roadmap?
Most products usually fail for the following reasons:
- Too much emphasis on business/technology & lack of focus on the other (technology/business): A very common aliment for a lot of product managers and often leads to the product managers firefighting and going through crisis after crisis. What usually happens is that there is a lack of delegation or either the engineering or business team leads are unable to deliver the results and end up getting the product manager to take their roles. The product manager should be the editor and get the teams to perform and not ended up performing for either teams.
- Too much features & too little room for experimentation or patience to work for the long haul: Product managers in corporations faced this problem more than in startups. Typically the startups are experimenting so much that they did not let the experiments to take its full course. What usually happened is that senior management ended up closing the product offering and not giving positive results or time for the product manager to take it further.
- Lack of integration between marketing, sales & product development, and that’s why growth hacking is important: A good product manager puts up a chart and look at everything from a top view. The feedback from customers drive how much marketing is required and how the product might morphed into, hence it is really important that the product managers adopt an integrated and data drive approach. What typically happens, is that they are too specialised on one side. The best way is to lay out all the different aspects of the product with a timeline and do a stacking of the priorities so that the product manager focus different things at different times. I have learned from experience that good product management is how one properly manages their time and not responding to crisis or business owners being anxious. Don’t be fooled by people who tell you how intense startups can be and you are firefighting fro your product. You can achieve work life balance by managing the integration smart and planning out well on how the whole thing comes together.
- Execution only limited to specific points of time and not over-arching: A lot of product managers only focus on the pre and product launch dates and totally ignore the post launch. The reason is that most people do things in a last minute fashion and do not keep a consistent schedule. Hence, the product manager should ensure to plan a balanced and consistent schedule where pre, during and post launch activities are happening and keeping the various teams in check.
Once we understand how product managers can screw up, then it would be easy for me to offer some advice on how we should decide the product roadmap:
- Determine the business objective of the product: The product manager and the business owner determine the business objective of the product, and worked out what metrics constitute the success or failure of the product. They have to convey the same objective to both business and engineering teams to ensure that everyone is on message with the outcome.
- Align the team on product development, sales, marketing & customer data collection to business objective with timeline and milestones: Set out the plan with a timeline and milestone chart for all the teams so that everyone knows what everyone is doing.
- Do not be distracted by your competitors and say no to adding new features or total perfection: A product manager should know about the direct & indirect competition out there but do not be led by the competitors when it comes to the product. The biggest mistake that most business product managers make is to tell engineering to add more features with the misconception that they will be able to sell to customers. I learned from brutal experience that business owners or product managers often make excuses that they cannot sell a product because of missing features or features that do not exist. That is when you know whether this person is really good at what he or she is doing. It is also the reason why a lot of engineers in Asia are cynical about startups because a business product manager cannot do what he or she is supposed to be good at selling and marketing the product. Always take the product to 80-99% perfection and let the market tell you how it should move, and not try to achieve the third law of thermodynamics where that perfection does not exist.
- Hold yourself accountable to a set of metrics: The product manager needs to set of metrics for himself and his team to achieve. The metrics must also be flexible such that the circumstances might change to force the team to pivot the product to another business objective.
- Ensure everyone is on message: A tip to do this is to write the press release for the product launch or other related matters before the launch such that it focuses the team towards aligning the product development, sales & marketing with the press release. Of course, staying on message whether it’s the technical or business lead with the press is important.
- Relentless execution from pre, during and post-launch of product: Getting the team to execute flawlessly and ruthlessly without fail is important. In Asia, we are still grappling with quality compared to the US. The product manager needs to introduce the culture of taking the time to get it right than to rush things. Most product failures and firefighting arise from teams getting confused messages from business owners. The product manager has to be relentless in the execution phase of the teams.
A Tale on Product Management: Hacking Google Voice into a SMS server for the United States Market
One of the most interesting things I have done in my career as a product manager is to deploy a simple short message service (SMS) for United States (US) customers to post their updates to our advertising platform in Singapore. This innovation incurred only two days of development time and was done at 5% of the original estimated cost, savings that were crucial to our bootstrapped startup. At that point in time during 2010, I was the co-founder and Chief Technology Officer (CTO) of a Singapore-based startup called Chalkboard. Chalkboard was an advertising platform that helped business owners with physical stores target location-based ads to consumers in the vicinity. Chalkboard worked through third party mobile applications or online websites on location aware web browsers.
Our customers were busy owners of small-medium enterprises with little time to deploy daily promotions and advertisements. Therefore, we designed our platform to be as convenient to use as possible. Upon signing up with our service, customers would provide basic information of the business location and the first promotion message (within 140 characters). Promotion messages could come in the form of today’s specials, seasonal offers or discounts or a new product launch. Customers could send as many promotion messages as they want at any time or day, with the latest message replacing the last one. We offered three input methods for them to update their promotion messages. The first method was a web-based interface through our platform. The second method was through a tweet sent from an associated business Twitter account. The last method was to send a SMS message from the business owner’s mobile phone to a designated local number.
The SMS method was very popular in Southeast Asia. Older business owners, who are less tech savvy, often updated their promotion messages using SMS. Our data showed that in Southeast Asia countries (Singapore, Indonesia and Malaysia), approximately 50% of our customers used the SMS method, followed by 45% using the web interface and only 5% used Twitter.
By late 2010, our business had expanded to the US. We were about to start deploying our service to trial customers in the city of San Francisco. Due to geographical reasons, deploying the SMS service was a tricky matter. At that point in time, to keep things in context, SMS to web services such as Twilio were not available. If we followed convention to set up an SMS server in the US, it would require us to fly a software engineer to US to do so and incur costs that would be significant to our bootstrapped startup.
Yet, our profiling of US customers and experience in Asia indicated that US business owners above 40 were likely to use the SMS method. It became crucial to validate our hypothesis, as we did not want to alienate this segment of US customers. Any solution had to satisfy the important constraint that we do not stretch both financial and engineering resources.
After brainstorming with my team, we came up with a solution. We worked intensively over two days to build a SMS system consisting of a mobile handset placed in Singapore and a pre-paid SIM card from the US that could receive free incoming SMS. We utilized a free service called Google Voice available in the US. First, we paired the business owner’s local US mobile number with our platform, and informed the business owner to send their latest promotion message to our designated pre-paid US mobile number. The pre-paid SIM card number was linked to a Google Voice account. The SMS from the business owner would reach the Google Voice account in the form of an email. We then extracted the promotion message from the email using the Google Voice API and pushed it to the consumers. This solution incurred only 5% of the estimated cost of setting up a SMS server in the US.
Upon implementing and experimenting our service in the US market, we discovered that very few customers (less than 1%) used the SMS method to input their promotion. Most US customers (70%) used Twitter instead. As there was insufficient traction in the US market with the SMS method, we removed the SMS service and offered only services based on Twitter and the web dashboard.
The impact of this innovation made a difference to how our business would operate in the US. First, it allowed our sales and marketing team to collect quantitative data and understand the profile of our customers in the US. Second, it incurred very little financial and engineering resources, which were then better used building technologies crucial to the core business. Finally, the solution could either be scaled up (by installing a US SMS server) or removed quickly without hassle.
Epilogue
The product manager has to balance between different priorities and aspects on the business of a product. We are often distracted by the competition and not focus on saying no when we need to. Continuously iterate and improve the product is not just engineering but there are other engines such as marketing and sales at work which are part of the whole package. To come back to the theme of the talk, always remember what Craig Federighi says, “New is easy but right is hard.”.
Author’s Note: Here are the slides for the whole talk I have given in Hackers & Painters on 15 Nov 2013 at Blk 71. I thank the organizers for inviting me to do this talk on product management.
New is Easy but Right is Hard: Hacking Product Management from Bernard Leong
References:
[1] Ben Horowitz, “Good Product Manager/Bad Product Manager”
[2] Ken Norton, “How to hire a product manager“.
[3] Ian McAllister, What distinguishes the top 1% of product managers from the top 10%?.
[4] Jeff Weiner, How to Spot the Five-Tool Superstar
[5] Jack Dorsey, The CEO as Chief Editor.
[6] Eric Ries, The Product Manager’s Lament.