Welcome to the second article of our series on the essential elements for crafting outstanding Minimum Viable Products. This article explores the critical aspects of ownership and team dynamics, pivotal for the effective development of any MVP. There is, of course, a lot more to get into on the topic, so remember to check out our other posts in the series on Business vision and prioritization in MVPs and Technical capabilities, metrics, and feedback in MVP development. Together, this article series will guide you on how to build successful MVPs.

Articles in this series:

Part 1: Business vision and prioritization in MVPs

• Lack of business vision
• How not to fail?
• Making everything a top priority
• How not to fail?

Part 2: Ownership and team dynamics in MVPs

• Lack of ownership
• How not to fail?
• Engineers not working closely with the Business
• How not to fail?

Part 3: Technical capabilities, metrics, and feedback in MVP development

• Core IT as a bottleneck
• How not to fail?
• No success metrics & feedback gathering
• How not to fail?
• Conclusion: How do we ensure you won’t fail with your Minimum Viable Product?

Lack of ownership

We had an idea, we transformed it into a vision - and prioritized what needs to be delivered to our customers as a Minimum Viable Product. So now, we need an accountable person to turn the vision into reality. Who would be the most suitable candidates for the task? Engineers? Managers? Analysts? Many companies are failing at this step because finding a skilled Product Owner is tricky. Let’s take a look at what this person should do and…think. Ownership is not only a skill but also a mindset.

You can find one of the best explanations for the accountability of the Product Owner in the Scrum Guide. “The Product Owner remains accountable for it (goals and backlog delivered, ed.) being accomplished and for the value delivered.” There are two key areas of product ownership in this sentence: backlog management and value delivery. A Product Owner is a person, who can translate the business vision into a decomposed, granular set of functionalities, understandable both by Business People and the Engineering Team. Product Owners should not only understand the business processes and customer journey - but also should have at least minimum knowledge of the software delivery process. Backlog management seems to be closely related to software delivery, leading many companies to assign that accountability to Software Architects - which is a common mistake. Why? Because the Product Owner is accountable for the value delivered to the Customer. The Product Owner's primary focus should not be the software created, but the value delivered with it. The delicate balance between the software delivery world and the focus on business value is a key factor that makes ownership a tricky part to address during the creation of a Minimum Viable Product.

Here are the common mistakes in addressing ownership:

• The lack of one person accountable for the Product: Lacking Product Ownership, coupled with distributed accountability, often results in decision-making bottlenecks (or even deadlocks) during Minimum Viable Products delivery.
  
  
• Making Software Architects accountable for the Product value delivery: The best Software Architects, despite having a deep understanding of Business Domain and Processes, are not Business People. The tendency among Software Architects is to deliver flexible, reliable solutions - but the focus on business value requires different skills than being an architecture expert. Hiring Software Architects to be accountable for business results can be similar to hiring mechanical engineers to win the Formula #1 race - there will be mechanical engineers who are also the best drivers, but it is not a common case. Similarly, Steve Jobs without Steve Wozniak probably wouldn’t have made Macintosh, but without Steve Jobs' vision and ownership, Steve Wozniak would probably not have succeeded with Apple becoming a top brand.
  
  
• Focusing on Product scope instead of Product Value: This is a common mistake that Product Owners may make - treating the successful Minimum Viable Product release as the moment when the Product is available for customers, instead of the moment when the Product achieves business goals and delivers the expected value for end-users. During the delivery phase, there can be changes in the market to which the Product Team should react and sometimes even modify the business vision and priorities. A good Product Owner should be brave enough to change the Product scope based on the market situation and customer feedback.
  
  
• The “busy” Product Owner: It is the common mistake many organizations make when setting up a Minimum Viable Product Team. Product Owners’ full focus should be on the MVP delivery, its market, stakeholders, and surroundings - while there are still organizations expecting the person to be also involved in “business as usual.” This stride between Product and Business Operations results in Product Owners' lack of time and mental capacity for the Product and the Delivery Team. It is also a reason for delayed decisions (or even lack of them if needed) or missed opportunities to make changes to the Product once they are needed. In our opinion, this is one of the biggest factors why Minimum Viable Products fails despite a well-defined business vision and great ideas.
  
  
• Non-decisional Product Owner: Too “low in the hierarchy” of the organization. The Product Owner should be “powerful” enough to make independent decisions on the Product scope and the priorities. Accountability and ownership should be entrusted only to those who are capable of making independent decisions and handling the consequences.

How not to fail?

At platformOS we understand that Product Ownership of Software Solutions can be difficult for organizations that are overworked, understaffed, and maybe not familiar with Software Delivery. That is why we are committed to taking accountability for product management and freeing you to focus solely on shaping the business vision  - a role that aligns naturally with most executives and business experts. Our MVP Blueprint is designed to support you in building the business vision, goals, and value definition - while we are willing to take delivery on our shoulders, together with our partners specializing in your business domain. Our approach stands out in the IT market, as we won’t expect you to specify each element of the Product, but instead, understand what you want to achieve with it. And achieve it with you!

Engineers not working closely with the Business

Tailor-made software products are like making a movie - multiple elements make it an Oscar-level blockbuster. Each person on the movie crew should be at least aware of what the movie should be about and the kind of atmosphere the film work should create in the cinema hall. Let’s take Bridgerton & Napoleon for example - the historic area of the action is (more or less) the same, the palace locations might be the same, and even the actors, props, and film crew could be the same. So if you won’t provide screenwriters with the scenario and intended message for both works - and rely only on the historical era, you are going to have a documentary about the past instead of heartbreaking battles (in Napoleon) or an enchanting fairy tale about love (in Bridgerton).

The very same thing happens with not including the Engineering Team in Business Value creation, prioritization, and stakeholder review of Minimum Viable Products. The very same thing happens if you fill the Engineering Team only with software developers without any business people. If your engineers rely only on a list of priorities and functionalities, they will probably deliver the MVP - but it might lack the flexibility needed to make changes during and after its release. Business structure and intentions are key factors for the best software architects - without this context, they are unable to ensure that Product Architecture fits the value proposition and long-term operationality.

Here are some common mistakes in organizing the work and communication with the Delivery Team and Business Stakeholders:

• Treating the Delivery Team as a software shop: The common mistake you can make excluding Software Engineers from business value creation and presentation. Business context, stakeholder structure, and customer definition should be reflected in solution architecture - so once the Delivery Team does not have it (or does not understand it) - they will create a Minimum Viable Product which won’t be flexible enough to adjust to necessary changes.
  
  
• Throwing requirements and waiting for results: Software Delivery is similar to the creation of a movie - movie producers and directors are present at every step during its creation: screenplay, costumes, hiring crew, editing, etc. It is a better practice to review the increments and even test partially-working Minimum Viable Product once it is created - than do it only when the Product is fully created. You may miss the change opportunity or react if Product Development is leading to an outcome that is not what you expect.
  
  
• Product Owner as a single point of contact to the Business Stakeholders. The era when software developers may miss soft skills is long gone, so it is a bad practice to play a “deaf phone” between business experts and engineers. Instead, encourage your engineers to build relations and work closely with product stakeholders - by doing so they can better understand the product vision and value proposition. They can also reflect their structure and relations into the created solution, making it more flexible.

How not to fail?

At platformOS, we recommend building a mixed team of engineers (coming from platformOS and platformOS delivery partners) - and your business experts. We support your Business Leader in defining value proposition, business vision, goals, and marketing for the Product - while our Product Owner will focus on the vision delivery with the team. We also involve a Solution Architect, who is not only a Software Development expert - but has a deep understanding of your business domain. Our platformOS toolset requires the Delivery Team to focus on what the most important is - business features delivery and operations of your Minimum Viable Product - and its further development.

Previous article in the MVP series:

• Part 1: Business vision and prioritization in MVPs

Next article in the MVP series:

• Part 3: Technical capabilities, metrics, and feedback in MVP development