Your ideas could be messing up your product roadmap. Yes, you read that right. Wait, aren’t great ideas the fuel of a good product roadmap? Sure, to some extent. But are you suffering from challenges like having a hard time sticking to your roadmap and delivering against it? Half-done or low-quality features? Constantly switching priorities, or too much WIP? Well, it may just be because of your ideas.
First, let’s clarify what I mean by roadmap: …
Read the remainder of this post on ProductCraft
By René Rosendahl
I have written before about ease of use and the key characteristics of applications that are perceived as user-friendly. In this post, I’d like to dive deeper into what I call the “mental model” that underlies applications. I would define the mental model as the intuitive perception a user has or develops about how an application is organized and how it performs its tasks.
The mental model has two key components:
- The information architecture: How do the various elements used within an application relate to each other?
- The process flow: Which steps does the user of an application have to perform to accomplish a task and what states do the elements of the application move in between? What business rules apply?
The reason I wrote earlier that the user may already have a mental model in mind when starting to use a new application is that none of us is a blank slate. Based on prior experiences, we already have several very specific mental models we’re using or trying to apply when confronted with an unknown application. Let’s look at a few examples of existing mental models we already have:
In the context of Lean Product Development, there are now a number of acronyms in circulation among Product Managers and Agilists and many of them are similar and seem to overlap. In essence, they are all rooted in the belief that it doesn’t make sense to launch and release complete, feature-rich products which take many months (or even years!) to develop without first obtaining market feedback to validate that one has a good understanding of the problem to be solved and a viable solution for it.
Here is how I personally make sense of the various 3-letter acronyms and related concepts (full disclosure: this is my thinking and may not fully mesh with the official definitions):
- Experiments: When we put up experimental landing pages describing a product with means to “sign up” for more information etc, there is no product here, at best a description and/or depiction of a potential future product. While great for learning, I would not use any terms that include the word “product” because we really don’t have one yet. The same applies to mock-ups, prototypes, etc. Those make no product although these artifacts can be very useful learning devices. Experiments take place before an actual product exists.
- MVP (Minimally Viable Product): This is a production-worthy actual product with the smallest feature set to make it useful for users and allow the company to obtain feedback from the market, which can then be used to further iterate on the product, including more significant pivots. The MVP has hopefully been validated by earlier experiments before being built. One catch: If we release what we think is an MVP and the market response is horrible and it crashes and burns (it doesn’t meet market needs and fails defined product success measurements), I would argue it wasn’t actually viable to begin with. While not always fun, a failing MVP is a good thing (remember “fail fast”?) because the early learnings will result in significant savings because we don’t end up developing the full product, just find out months later that it fails. The MVP is about validation and obtaining market feedback.
- MLP (Minimally Lovable Product): Some found that certain MVPs were so minimalistic and spartan that they weren’t appealing to users. What was missing was the ability of users to form an emotional connection to the product. Hence people started using the term MLP to denote that the product must be enjoyable for the users. Then again, one could argue that maybe then the MVP as such wasn’t really viable since it was missing things to make the product compelling. The MLP emphasizes the emotional connection with the users.
- MMF (Minimally Marketable Feature): The MMF is very close to the MVP (at least in my mind), except it focuses on marketing the product. Maybe this distinction is more significant in cases where the users of the product are not the same as the people who buy and pay for it. The MMF is about wether a product is sufficiently developed in terms of feature set to be marketed and sold.
So really, apart from early experiments, MVP, MLP and MMF are all very closely related; they just seem to each emphasize certain aspects more than others.
Product folks out there, does this resonate with you?
As agilists, we are all fighting – to various extents – the perception that Agile is a set of processes, techniques, and (if we’re lucky enough that people understand this) mindsets to optimize software development teams. To some degree I can’t blame people for thinking that because that’s kinda how Agile got started. But nowadays Agile is taking a very holistic approach, a perspective that goes far beyond helping a team of developers function better. By the way, when I say “Agile”, I’m including Agile scaling frameworks as well as Lean and related product development approaches (so yes, I’m casting a pretty wide net, which is reflective of the close relationships between these different knowledge areas).
Here are additional angles Agile is looking at the world from and tries to impact:
- Organizational agility: enabling the organization to act and react quickly to environmental and market conditions.
- Portfolio management, i.e. understanding size and benefit of high-level initiatives and making optimal decisions for the business. Working on the right things (in the right order).
- Systems thinking (vs. local optimizations), aimed at optimizing the whole process of value delivery, not just software development.
- Removal of waste in processes and shortening cycle times of value delivery (not just creating shippable code).
- Making decisions based on economical and empirical considerations.
- The Lean Agile mindset which influences leadership style and organizational decision making.
- Organizational culture, including, but not limited to trust, respect, empowerment, etc.
- Organizational design and structure as well as performance management and recognition approaches.
- Product development approaches, e.g. the Lean Startup.
- Drive away from industrial era management beliefs and styles.
- Accounting practices impacting if and how capitalization is practiced, budgeting and planning.
- Appropriate metrics and KPIs.
- Technical practices (CI, CD, DevOps) and quality practices (test automation etc.) and technical craftsmanship.
- Architecture (think emergent architecture, loosely-coupled components, micro services, etc.)
- Relentless (self-) improvement at all levels. Kaizen.
- Team and interpersonal dynamics.
- Team and organizational health.
- Product innovation.
I probably forgot a few elements, but you get the gist. This is why agilists want to engage with and influence various levels in the organization, including senior management, and individuals in
- Engineering, technology, architecture, quality (obviously)
- IT infrastructure
- Product management
- Project management
- Finance & accounting
- Human resources
Hopefully over time the limited perception of Agile will be corrected by people and organizations understanding the holistic nature of Agile. With that approach, we can really unlock and enable the potential of an organization and its products.
I’ve recently come to a realization: I like products.
I find it enjoyable to research products, compare features, look at reviews, and pick the seemingly best one. It is satisfying to then hunt for the best price and get it as cheap as possible. Once acquired/delivered, it’s fun to unpack, explore and assimilate it into daily use. I’m the kind of guy who actually reads manuals/instructions and makes sure I understand and – where possible – use all the available features. Even months or years later, when I’m using a product, I still remember why and where I bought it and I really appreciate good design, manufacturing and useful features. And aren’t there cool things to buy these days? It’s hard not to be pleased with items such as the iPhone, big screen TVs, cars, and even a good dishwasher due to their usually high quality, reliability, design and features. To a large extent, the same applies to well-designed web sites and software. They’re fun to use and help meet a user need in a productive and elegant manner.
Just 15-20 years ago, it seems that products weren’t as cool, sophisticated and useful. It was more about the basics. The stuff we nowadays use is so much cooler as well as more affordable than back then. And who knows what’s still to come?
The other part of my realization is that not everyone loves products like I do. Maybe it’s stereotypical, but as a generalization I would take a guess and say men are much more likely to be appreciative of good products. Somehow I don’t know too many women who have the same love and appreciation for products, who research them, read manuals, and get excited about cool features. Is it that they’re just more into people vs. things or that while men are gadget aficionados, women tend to be more into clothes and decorative vs. functional items? (Yes, I know, it sounds even more stereotypical now…) There’s just a different level of interest there.
Whatever the case, I’m quite excited about all the cool products available today! This is a good time to be a consumer!