A Minimum Marketable Feature (MMF), the smallest set of functionality that must be realized in order for the customer to perceive value.
A feature is something that is perceived, of itself, as value by the user. “Marketable” means that it provides significant value to the customer; value may include revenue generation, cost savings, competitive differentiation, brand-name projection, or enhanced customer loyalty.
Further Reading
BOOK:Agile Product Management with Scrum by Roman Pichler
Roman Pichler is one of the leading voices in Agile Product Management space, having expertise in digital products. He is an Author, Trainer & Consultant on Lean, Agile and Scrum. We interviewed Roman to know about his journey in Agile Product Management, myths about Product Owner’s role and what he wishes for Agile Community. Let us take you through our conversation covering varied topics;
Q1. To begin with, please tell us what inspired or motivated you to start your journey in the area of Agile Product Management? Why do you think it can make work better?
Roman: When I began working with product managers in 2001 while introducing Extreme Programming at a healthcare company, product and Agile seemed worlds apart. The product management practices I encountered were very old-school and waterfall. I had a similar experience when I taught Scrum to product managers at a telco company in 2004. Back then I thought that product management would have to be reinvented to take full advantage of an Agile way of working. Luckily, this turned out to be unnecessary. But I still think that the profession has tremendously changed over the last ten years influenced by Scrum, Lean Startup, and Business Model Generation.
Q2. How can one be a balanced Product Leader instead of being a Feature Broker or Product Dictator?
Roman: A balanced product leader is someone who actively listens to and collaborates with the stakeholders but is not afraid to make a decision when no agreement can be reached. To put it differently, a balanced leader is neither a feature broker nor a product dictator—neither a product person who relies on others to come up with ideas, mediates between different parties, and tries to broker a deal, nor someone who assumes that she or he knows best what needs to be done, makes all the product decisions, and expects others to fall in line.
Q3. Please share 5 myths about Product Owner’s role existing in today’s world. Why do you call them myths?
Roman: Here are some common mistakes I see people make;
1) The product owner is a tactical role responsible for managing the product backlog and working with the dev team. The strategic product decisions are made by someone else. The opposite is true in my mind: To maximise the value a product creates, product owners should lead the strategic and tactical product decisions, should be outward and inwards-facing.
2) A product owner is a type of project manager or team lead in Scrum. Product owners should manage their products, not the team and process. Agile development teams should be self-organising, and every product owner should have a qualified Scrum Master or coach at her/his side to support the team, teach the process, and facilitate organisational changes.
3) You become a product owner simply by attending a two-day training course. In reality, becoming a competent product owner is a learning journey that requires the individual to acquire and deepen a whole range of skills. This usually takes months and years, not days.
4) A product owner asks the stakeholders for requirements and gets the dev team to implement them. The opposite is true: Product owner and team are responsible for innovation. They regularly validate their ideas and collect user and stakeholder feedback and data on product increments.
5) A product owner owns any type of asset ranging from a product portfolio to a component. A product owner owns a product—an asset that creates value for a group of users and for the company. It therefore must create a user benefit or address a user problem, and it must generate one or more measurable business benefits. Individuals who own parts of a product like a feature or component, or who own a product portfolio should not be called product owners. This avoids confusion and create clarity about the core responsibility of a product owner and the required skills.
Q4. What are the challenges you faced while leading through shared goals? How did you overcome the challenges?
Roman: As the person in charge of a product, you are responsible for achieving product success. But to accomplish it, you usually rely on the help of the development team and stakeholders. At the same time, you can’t tell the individuals what to do, and you are typically not in a position to offer a bonus, pay rise, or other incentives. This raises the question of how you can align people. Part of the solution is to establish a set of shared goals—goals that people support and that help you progress your product.
The first trick with shared goals is to identify the right set of goals. I recommend using visionary, strategic, and tactical goals that are aligned and form a chain. The second trick is to get people’s buy-in. Important goals—typically visionary and strategic ones—should be agreed upon. This means that everybody is happy to support them without reservation. Establishing such goals takes time, and it can be tempting to shortcut the decision-making process, set the goal, and ask people to get on with it. But this often leads to lack of support and difficult discussions later on. In the worst case, people follow their own, unaligned goals.
Q5. What inspired you to gather your thoughts and write a book? Tell us one thing that you enjoy most while writing a book and what is the one most taxing thing?
Roman: Writing a book helps me reflect on my experience and consolidate my knowledge. At the same time, I hope that the readers will benefit from the contents! Before I started working on my last book Strategize, I felt that many product people lacked guidance on product strategy, and that there weren’t many books available that focused on strategy and roadmaps for digital products.
I really enjoy the creative act of writing. But working on a book can be challenging—just like any other bigger effort. There are difficult moments and setbacks such as slow progress, low motivation, an early review that indicates that more work is needed, to name just a few. These are great opportunities to learn and grow as a writer, product expert, and human being. But while experiencing these challenges, they don’t feel particularly pleasant, and initially I am not very grateful for the experience!
Q6. According to you, what is the current state of Business Agility and Agile Product Management across globe? How the future looks like?
Roman: I am not sure that my knowledge and experience is necessarily representative, but I think that many businesses still haven’t fully realised what Agile and product are all about. In the worst case, project managers are rebranded as product owners, groups of people are called squads, and there are now chapters and tribes.
But when you take a closer look, little has changed. The product owners are not empowered and don’t have the necessary skills; the organisation is still project-driven; and the teams are not cohesive, self-organising groups but collections of individuals.
Q7. Failure is an inevitable part of life. It is quite possible to fail while innovating. How can one cope up with failure and accept it?
Roman: The solution is to stop seeing failure as something bad, and embrace what some people call a growth mindset. Unfortunately, that’s easier said than done. I find that we can become very attached to success, to achieving and winning. Failure, then, is something we try to avoid, an unfortunate accident, rather than a mandatory part of the journey. But without failure, we don’t learn and grow—neither as individuals, nor as organisations.
Q8. Share 3 things you wish for Agile Community.
Roman: a) Kindness b) collaboration, and c) an open mind.
Q9. One question you think I should have asked you. Please answer that question too.
Roman: A question I often get asked is, how can someone working as a product owner or product manager be more empowered? While part of the answer is to get management support and possibly establish a product management function in the company, there are two things you can do on your own:
First, you can improve our expertise and acquire the relevant knowledge and skills. Knowledge is power as they say, and the more competent you are, the more likely are people to trust and follow you.
Second, you can increase our referent power, which is linked to how we are as a person. Being empathetic, kind, honest, patient, humble, acting with integrity and keeping an open mind will earn you the trust and respect of others. It will make it more likely that people will follow your guidance. What’s more, strengthening these qualities will make you a happier person too. How cool is that?
Roman Pichler is a leading product management expert specialised in digital products. He has 15 years experience in teaching product managers and product owners, and in helping companies improve their product management function. Roman is the author of the books Strategize and Agile Product Management with Scrum, and he writes a popular blog for product professionals.