How to Build Successful Products by Workday Director of PM
•Download as PPTX, PDF•
0 likes•58 views
This presentation will encourage you to embrace our era of constantly changing environment and teach you to adapt your product to the technological changes as well.
Recommended
Recommended
More Related Content
Similar to How to Build Successful Products by Workday Director of PM
Similar to How to Build Successful Products by Workday Director of PM (20)
More from Product School
More from Product School (20)
Recently uploaded
Recently uploaded (20)
How to Build Successful Products by Workday Director of PM
- 1. www.productschool.com How to Build Successful Products by Workday Director of PM
- 2. FREE INVITE Join 30,000+ Product Managers on
- 3. COURSES Product Management Learn the skills you need to land a product manager job
- 4. COURSES Coding for Managers Build a website and gain the technical knowledge to lead software engineers
- 5. COURSES Data Analytics for Managers Learn the skills to understand web analytics, SQL and machine learning concepts
- 6. COURSES Digital Marketing for Managers Learn how to acquire more users and convert them into clients
- 8. Predictions & the horizon of certainty
- 10. 3 STEPS TO EMBRACECHANGE 1 2 3 Product Roadmaps Market Opportunities Expiry Dates
- 11. Shorten your product roadmap Ship fast, often and iterate
- 14. Juggling with care What are you optimizing for? ❑ Velocity ❑ Features ❑ Quality
- 15. Protect your flanks Research and investigate your adjacent markets
- 17. Know Your Market 1 2 3 Dedicate Time Explore & Research Taste new, emerging areas
- 18. Build to deprecate Design features that are easy to dismantle
- 20. Deprecation is part of life Don’t be too attached ❑ Lifecycle of usage ❑ Address deprecation plan ❑ Avoid tight coupling ❑ Engineering + Product
- 21. Don’t fear change, embrace it
- 22. Shorten Your Roadmaps Protect Your Flanks Build to Deprecate Embrace Change
- 23. www.productschool.com Part-time Product Management, Coding, Data, Digital Marketing and Blockchain courses in San Francisco, Silicon Valley, New York, Santa Monica, Los Angeles, Austin, Boston, Boulder, Chicago, Denver, Orange County, Seattle, Bellevue, Toronto, London and Online
Editor's Notes
- In 2000 BC, if you asked an Egyptian to describe what the future would be like, they would probably be able to accurately predict the future for the next 500 years. Their lives would perhaps see more pyramids but otherwise, things would be stable. In the 10th century, if you ask an Anglo Saxon peasant what life would be like 200 years in the future, they might still be able to guess what pre-renaissance medieval life would be in the 12th century, but their guess of 15th century Europe would be way off. If you asked the same question to someone in the trenches of world war I, their imagination of the world would be off starting from 1930s. And since all of us were around at the turn of the millenium, if we were asked to guess people’s life in 2018, we would not have been able to foresee today’s world of the iPhones, Facebook and Amazon.
- What we are observing is the shrinkage of the horizon of certainty. The time window into the future upto which we can make reasonably accurate predictions has been rapidly decreasing. This has profound consequences for people like you and me. The product managers and product leaders of companies that are responsible for setting the vision for our teams. It is all the more important for us to ensure that our teams are keeping up with this pace of innovation. We have to make sure that our roadmaps are not out of date. As product leaders, it is our responsibility to actively think about this everyday and mitigate it the best possible way. In the next few minutes, I hope to share with you three strategies that I believe are critical for delivering successful products in this era of hyperchange.
- So for the rest of our time here, let’s talk about what you can do to make a change into being a successful PM. We’ll explore 3 dimensions that have made me a successful PM. We’ll look at examples for each of these traits and talk through scenarios where applicable. Please stop me at any point to ask questions. The point of this is to start a discussion and for it to not be a presentation/show and tell.
- In this era where change is constant, a roadmap that spans multiple years is typically rendered useless. These roadmaps are built on shaky and ever changing assumptions. It is therefore critical to have short roadmaps that span no more than a year with clearly defined assumptions that led to those prioritization decisions. Revisit this roadmap every quarter to reevaluate assumptions and relevance.
- Do you all remember the windows phone? Microsoft had an ambitious multi-year roadmap to merge their mobile and desktop OSes to create a fusion OS where tasks could be seamlessly handed off from one device to another. While this is an excellent idea in theory, the multi-year implementation meant that Microsoft was shipping phones that could not compete with the features of iPhones and Androids that were already available in the market. This is a classic example of longer product roadmaps ultimately resulting in the failure of a product like the Windows Phone.
- In this era where change is constant, a roadmap that spans multiple years is typically rendered useless. These roadmaps are built on shaky and ever changing assumptions. It is therefore critical to have short roadmaps that span no more than a year with clearly defined assumptions that led to those prioritization decisions. Revisit this roadmap every quarter to reevaluate assumptions and relevance. We all know about the delicate art of juggling the 3 parameters of velocity, features and quality as product managers. Companies like Apple focus on building high quality products even if it means that they compromise on the number of features while Facebook places a higher emphasis on velocity. As the horizon of certainty shrinks, skew towards velocity. It’s no use putting out a highly polished product whose sell by date has passed. Cut down features ruthlessly and ship as soon as possible. Quality is always hard to judge but be pragmatic. Ask yourself what is THE most buggy product that still delivers enough value and delight to the user base. While this looks like a compromise, remember that PMing is nothing but a study of compromises we need to make to deliver successful products.
- We all know about the delicate art of juggling the 3 parameters of velocity, features and quality as product managers. Companies like Apple focus on building high quality products even if it means that they compromise on the number of features while Facebook places a higher emphasis on velocity. As the horizon of certainty shrinks, skew towards velocity. It’s no use putting out a highly polished product whose sell by date has passed. Cut down features ruthlessly and ship as soon as possible. Quality is always hard to judge but be pragmatic. Ask yourself what is THE most buggy product that still delivers enough value and delight to the user base. While this looks like a compromise, remember that PMing is nothing but a study of compromises we need to make to deliver successful products.
- Disruptions happen all the time, but the nature of disruption is deeply misunderstood. Companies don’t directly attempt to build the next big search engine or social network. Instead, their focus is to go around the core strengths of major market players and innovating in adjacent markets. PMs often don’t add this time to their everyday jobs. Have dedicated time to study adjacent market spaces and potential opportunities. In essence, protect your flanks.
- An example that comes to mind is of Google and Facebook. Google’s core revenue generation is through display ads and search ads. A frontal attack on Google would be to build a search engine or display engine and show ads on it. However, Google has a huge head start on this. Microsoft tried to do this with Bing and failed. Google’s mission is to organize the world’s information and make it accessible. Their search platform allowed them to organize the public information available on the internet. Facebook decided to organize the World’s private information by building a social network and showing ads on it after the network was strong. Google totally missed out on this even though they had a 20% project that yielded Orkut, which was a moderately successful social network esp in India and Brazil that constitute 20% of the world population. But Google leadership did not see this foot they had in the social networking space and ignored the market until Facebook became too big and the network effects set it. 30-40% of the World’s digital advertising revenue is being made by Facebook. And we all know what happened next in their attempt to launch a social network.
- To guard against flank blind spots, encourage your dev team to spend a bit of their precious time in exploration via hackathons or 20% projects. While this comes at the cost of time that could be used to strengthen your core product, it’s worth it. To be able to come up with a good roadmap that caters to the market, it is important to be able to dedicate some time and effort spiking and researching new possibilities. This is also rewarding to the engineers in the team and allows us to have a taste of new emerging areas, like cryptocurrencies, without making hard pivots in product roadmaps.
- The example that comes to my mind about the perils of systems that cannot be deprecated is Google’s Android operating system. In their rush to ship features and reach parity with iOS, Google’s initial versions of Android made some rather poor choices that didn’t consider the continual changes the team would need to make to their operating system over time. For example, Android was built as a monolith that tied all the core APIs into the Android OS. This meant that new APIs were coupled to OS releases. The tight coupling of the OS and heavy usage meant that there was no way to deprecate and rebuild without disrupting the huge android community. After enormous effort, the Android team was able to rectify the situation by splitting the OS functionality from their APIs by introducing the GMS (Google Mobile Services) to update the core APIs.
- Given everything we talked about, it is clear that we don’t live in a world where products are built to last or remain unchanged. A critical part of change is deprecation. Many teams crumble under the weight of carrying hard-to-deprecate functionalities. When building features, always think about the deprecation plan and the lifecycle of usage for the product. Make your architects and tech leads address deprecation in their design docs. Avoid tight coupling of product features that make either impossible to deprecate without breaking the other. Make sure the dev team understands that all code and features are ephemeral and that they need to consider deprecation as a core part of design and engineering.
- Six years ago, while I stood atop Michelangelo's square, ML was milliliters and was the unit of measurement of liquids, not the word that gets VCs to open up their wallets. Uber was German for above and not how you got places. Tesla was a long dead genius, not the most desired car in town. This frightening pace of innovation and rapid churn in products can leave PMs and their products obsolete unless you actively deal with it. While there is no silver bullet to this problem, take solace in the knowledge that you might be one step ahead of your competitors by actively strategizing and dealing with this issue.