Google was a search box. Yahoo was a directory. YouTube let you search and play videos. Many of the best applications started with humble beginnings, simple user experiences, and demonstrable value to end users.

So why is it that many product owners over engineer their minimally viable product with too many “must have’ features, data integrations, user interfaces with an oversupply of bells and whistles, and other capabilities?

It’s been seven years since I wrote this post on simple agile product development about the collaboration required to engineer non-complex products. I challenged product owners that try to develop a death star or a flux capacitor and answer why product owners should target minimal marketable feature sets and then add features incrementally. I’ve begged product developers to seek out user behavior data and market research to define and better prioritize their feature sets. I also wrote a post on rapidly planning product MVPs and a whole book on Driving Digital that has a chapter dedicated to product development and management.

Critical Mistakes when Developing Product MVPs

Yet I still see product managers making some common mistakes

1. 1. Taking the desires of stakeholders literally and funneling too many of them into the product.

1. 1. Failing to define customer segments, user personas, and user roles when designing the customer journeys.

1. 1. Driving beautiful UIs instead of simple UXs and making MVPs overly complex to implement.

1. 1. Neglecting to ask end users questions (or asking the wrong questions) to help validate the value proposition and priority of new features.

1. 1. Forgetting how to use alpha, beta, A/B releases and other mechanisms to slowly introduce new UXs, design changes, and features incrementally by customer segment.

1. 1. Failing to engage the engineering team during the planning and development process to consider implementation complexities and alternative approaches that drive “good enough” results.

1. 1. Believing that “more is better” instead of “less, but implemented well is better”.

1. 1. Underestimating the effort in developing automated tests while pushing for more functionality, more data elements, and more capabilities that require a greater investment in testing.

1. 1. Leaving non-functional requirements like performance criteria, what usage data to collect, and SEO requirements as “technical criteria” and expecting technologists to implement them with little business guidance or budgeted time to implement.

1. 1. Underspecifying business reporting, administrative tools and other “back office” functions that are important to manage related business functions.

Establishing Product Development Guidelines and Guardrails