An MVP ‘thin slice’ allows the product team to align a key business process for clear desired outcomes and value to ones who are ultimately paying up. This thought needs a little extra when it comes to Platform MVP.
A platform (data or otherwise) supports multiple channels (desktops, mobile, voice, etc), business applications that consume data via services and data sources that pour data into the platform.
The hour-glass approach allows to establish a platform MVP: a small set of capabilities critical for the key business application, useful & usable for at least two more applications and are scalable for many more business applications.
This approach matches the metaphor of an hour-glass. It is broad on the top covering a few business processes, narrow in middle for the minimal set of capabilities and broad at the bottom covering multiple data sources.
Platform MVP to Replace a Legacy Platform
When replacing a legacy system, it is common to take the Strangler Approach. However, for a platform, this runs a risk of creating a platform that was too close to the key business process and the relevant data sources. The platform runs the risk of being tightly coupled with that key business process.
The Platform Product team should focus on providing a minimal set of capabilities that would be useful for the key business application. These minimal set of capabilities should also be sufficiently useful for at least two other. The platform capabilities should be sufficiently useful for the other two business processes so they would invest enough time with the Platform Product team so the Platform ProMa can analyse their possible needs.
Based on his popular blog, Dinker Charak brings a collection of tools, methodologies, and some unexpected approaches to Product Management. He also talks about his entrepreneurial journey from the eye of a Product Manager and discusses the strategy and its failures.
Dinker offers an enjoyable potpourri of helpful advice and ideas from his experience in consulting and his experiments with building products.
– Sriram Narayan, Digital-IT management consultant, ThoughtWorks & Author Agile IT Organization Design
Dinker is a magician — in a crisp book that is light and easy to read, he has packed in more than a semester’s worth of high priced B school education, and several years (and many dollars!) worth of lessons from a startup. Pick it up, you will not be disappointed.
– Naren Nachiappan, Co-Founder, Jivox
A brilliant resource for all consultants, irrespective of the role they are in, and not just Product Managers. Dinker has poured his years of experience into this one book. He covers entire life cycle of a product/business evolution and introduces a lot of handy artifacts – checklists, frameworks, tools, etc. – that can be readily used at various stages of evolution. He sheds light on the real-life charms and challenges of building a product and does so in a simple yet eloquent manner. Keep an open mind and give this book a read – you’ll later on thank him for providing a wealth of knowledge on the topic.
– Devangana Khokhar, Senior Data Scientist & Strategist, ThoughtWorks & Author Gephi Cookbook
Dinker is quirky, interdisciplinary and full of real-world wisdom. The same could be said of this breezy new book on Product Management.
There are plenty of simple ProMa tools you can use every day – ‘Product in a Box’ and ‘Five buckets of Product Management’ stand out. There is also the philosophical exploration of the subject through lenses as varied as Indian materialism, Francis Bacon (he of the scientific method), and Rene Descartes. Most remarkably, there is a vivid tale of a failing startup – something any product entrepreneur will benefit from.
If you’re a product manager or work with these sometimes-mysterious creatures, take a copy on your next flight. You’ll have a spring in your step when you land.
– Nagarjun Kandukuru, Principal Digital Strategist, ThoughtWorks
"Who is my customer? Everybody, anyone you can think of—"
"Who is my competition? Amazon, Google, Netflix— (add any popular name in the Silicon Valley)."
"Who am I? I am a technology company who happens to do X (the industry this company should be in, till I probably walked in)."
This is what I keep hearing from the C-Suite at the clients I am engaged with.
In this world of needing and wanting to reinvent (or else—you are doomed), the most common response I have seen people resort to is by saying we have moved to a "product organisation" or an "experience organisation". This, no one will argue, needs change.
However, Dinker continues to argue that the challenges lie in the core philosophy. It’s not an easy journey. I can guarantee you will fail if you thought reading this book will solve the challenges of "product thinking".
But here lies a great starting point from a great product philosopher, thinker, transformer, doer and practitioner, and above all, a great colleague and a friend.
Read on, but engage with him when you get a chance. He will not fail to surprise you.
– Sagar Paul, Client Services – Strategic Accounts, at ThoughtWorks
Why the Book #ProMa and Why Now?
Product Management is an accidental and a new role. It is gaining importance as a pivotal for a Product based business. Being new, there are no set definitions, job descriptions or even well-known educational courses. In fact, in IT industry, Product Managers come from the most diverse set of background and may not always be technical or even have an MBA.
As opportunities for Product Managers grow, it is natural that consulting organization start offering this as a consulting role. This increases the complexity of the job.
As the role evolves, all this leave a new-comer with lots of questions about how to go about the job.
This book is based on the real and personal experience of being in this role in a variety of situations and draw upon the experience and output of last decade. Thus, the book also presents an opportunity to establish some Thought Leadership in this domain.
About the Book #ProMa
“Based on his popular blog, Dinker Charak brings a collection of tools, methodologies, and some unexpected approaches to Product Management. He also talks about his entrepreneurial journey from the eye of a Product Manager and discusses the strategy and its failures.”
Each chapter is complete in itself and focused on a specific theme. Some chapters may rely on concepts introduced in details in a previous chapter. However, a reader can still benefit from it without know details from the earlier chapters.
Some ideas are results of extended discussions, an opinion sought or a point-of-view constructed for a client. All of them are the result of sincere effort to produce something useful and usable. And at times, something unique.
The book is divided into three sections.
The first section (chapters 1-6) is about various tools & methods I have created and used for Product Management. These include the Product Management Canvas and the Product workshops I run.
The second section (chapters 7-18) is about various thoughts and ideas that I have around what it means to be a Product Managers and around Product Management.
The third section (chapters 19-26) is about entrepreneurship and based on my experience as a founder who hasn’t succeeded yet. It also has some ideas on team building, mainly around a novel concept of Dirty-Work Group.
Key Takeaway from the Book #ProMa
The book covers the entire lifecycle of a product/business evolution and introduces a lot of handy artifacts - checklists, frameworks, tools, etc. - that can be readily used at various stages of evolution.
There are plenty of practical ProMa tools you can use every day and also the philosophical exploration of the subject through lenses as varied as Indian materialism, Francis Bacon (he of the scientific method), and Rene Descartes and Sociology.
Who is the Target Audience For the Book #ProMa
The First Timer:
Has a tech, business or design background. Is now a Product Manager for a B2C product. Is poly-skilled enough to get the job but worried if is knowledgeable to pull it along.
An Experienced ProMa:
Has been a ProMa in an Enterprise that is building a B2B product. Has done MBA and/or has a technical background. With the expectation of B2B products to respond to market at speed of startups and with Usability of B2C products, is looking for ideas on how to reinvent the attitude towards this job.
An Entrepreneur / Founder:
Realising that a Founder is the first Product Manager of the startup’s Product, the Founder wants to ensure a proper approach is taken and not detail falls through the cracks and is looking for tools and checklists to ensure all basis are covered.
ProMa help monetise a business opportunity via a Product. For key business owners, it is important to understand what a ProMa does and how does a ProMa think. This book can help them understand the variety of aspects of a ProMa, gain a better appreciation and establish meaning and deep partnerships.
About the Author of the Book #ProMa
Dinker Charak has over 17 years of rich, diverse experience in the software industry building products that matter.
During his career, he has built software products that have been part of Real-time Operating Systems, Paperless Offices, Home Automation, help develop Online Video Ads business and founded a startup. Dinker was worked at Fermilab (US) and contributed to CERN (Switzerland), two top research lab that conducts basic research into particle physics. He holds a patent in Advertising Technology.
As personal interests go, Dinker holds Product Management Workshops for startups in collaboration with IIM Ahmedabad, CIIE, NASSCOM's 10,000 Startups and ThoughtWorks.
Dinker has done Master in Computer Application from International Institute of Professional Studies, Devi Ahilya University, Indore, India.
I gave a talk to the students of Executive MBA at Institute of Product Leadership, Bangalore on 19th Nov 2016. It was a conversation around Product Management, industry practitioners approach to it and what’s new in this domain.
I also shared some new ideas I am toying around with and sought the feedback. It was a lively discussion.
I am among the millions of Apple’s iOS Music App and Podcast App users. I am certainly not only one who struggles with the design dissonance in their app. Here are my top 2 rants:
Design Dissonance in Location of Play Button
The Play buttons are in opposite positions. I always have to look and think where to click. This does not allow for muscle memory for someone using both apps very frequently. What happened to “Don’t Make Me Think“?
Podcast app provides two extremely useful features:
15 second skip forward or skip back
None of these are there in the Music app. Folks often go to sleep listening to music (a la Podcast) and need this function. Everybody like to revisit that beat or the clever wordplay. So skip back is a cool and useful feature to have.
Product Management Failure
Both cases are symptoms of failure of Product Managers.
It is as if the Product Managers of Podcast App and Music App don’t talk to each other or don’t like each other enough not to learn from each other.
It is also the failure of the Product Manager of Apple’s App not to drive Design Cohesion across the app that Apple builds.
A backlog is a list of features or technical tasks which the team maintains and which, at a given moment, are known to be necessary and sufficient to complete a project or a release:
if an item on the backlog does not contribute to the project’s goal, it should be removed;
on the other hand, if at any time a task or feature becomes known that is considered necessary to the project, it should be added to the backlog.
These “necessary and sufficient” properties are assessed relative to the team’s state of knowledge at a particular moment; the backlog is expected to change throughout the project’s duration as the team gains knowledge.
The backlog is the primary point of entry for knowledge about requirements, and the single authoritative source defining the work to be done.
Not That Backlog
Various terms exist for a backlog being used in Agile development. Based on scope / tradition, terms Story Backlog, Feature Backlog, Epics Backlog, Development Backlog and at times Product Backlog too are used.
I will refer to these as Story Backlog so I can differentiate it with the Product backlog I am introducing in this write-up.
The agile story backlog in Scrum is a prioritized features list, containing short descriptions of all functionality desired in the product. A typical Scrum backlog comprises the following different types of items:
A story backlog is a prioritized list of work for the development team that is derived from the roadmap and its requirements. The most important items are shown at the top of the story backlog so the team knows what to deliver first. The development team doesn’t work through the backlog at the product owner’s pace and the product owner isn’t pushing work to the development team. Instead, the development team pulls work from the story backlog as there is capacity for it, either continually (kanban) or by iteration (scrum).
A Product Backlog is prioritized features list, containing short descriptions of all functionality desired in the product, with a business value for each feature clearly quantified along with source of the feature request / inspiration.
Product Backlog Card
A take at what a Product Card can look like:
Theme / Module
Action – Expected Result / I want to – So That / Feature / Inception time Epic
Success Metric (to judge value delivered)
Failure Metric (to trigger a re-learn / re-analyze)
I am still not sure if Priority would still make sense given that Value Ranking is there. The reason I have added it is because Priority represents the perspective on person who is creating this card and Value Ranking is a quantitative analysis based on weightage. Value Ranking is a kind of check on the ‘gut feel’ or ’emotional’ Priority.
I think Source is important. We should link back to the CRM entry, the social media post, a market study, email, etc that lead to creation of this. It is important to refer to that original content which can be referred to as-is in future and considered as ‘interpretation free’ source which a ProMa used.
Scoping Product Backlog Card
How much work is a feature? There are some questions that a ProMa should ask to give BAs, IMs, Dev a good idea of breadth of work involved. There is, always, more to a feature than just implementation. Look at the suggested list to get an idea what I mean here:
Is a GTM time identified?
If yes, date?
Does it need marketing collaterals?
Does it need sales collaterals?
Does it need support collaterals?
Does it need user collaterals?
Does it need change in process?
Does it need change in people & behaviour?
Does it need change in how users interact?
Does it need change in tech?
Does it bring in regulatory & legal aspect?
Does it bring in un-handled regulatory & legal aspect?
Does it need extra/new licenses?
Does it get covered by existing licensing model?
Security & Safety
Does it need extra security focus?
A yes on any of these, will affect the scope of work and for folks other than the Devs. It is important to look beyond the functionality during implementation.
Prioritizing Product Backlog
Quantifying Product Vision
A feature can be seen to provide / contribute to one or more of following values at various levels:
Based on the vision, these six can be given various weightage.
Eg: 1/ A product like say ‘Am-Behind App’ is playing catch up on feature parity with competition, the weightage can be:
There have been some question on how introduce Product Thinking and Product Management role during Project Inception. I and few other colleagues have been discussing theProduct Management role (ProMa) topic a lot.
As of today, this is how I see the flow. This flow is heavily influenced by experience on one day Product Management workshop that have attended by over 100 folks till now and various inceptions I have attended.
We follow the same visioning as we do in Inception. However, when we do epics, we convert them into a Product Backlog. Each Product Backlog will lead to multiple stories. What is different in a Product Backlog is some quantification of business value it delivers and metrics on how to measure it.
When stories go live and get consumed by users, we can measure and learn. This learning is brought back as part of analysis and grooming on the Product backlog (not Story / Development Backlog).
Re-prioritization of Product Backlog can affect the stories that picked up next.
More on this in coming days as it gets ironed out. Including what does a Product Backlog looks like.