A Practical Approach to Agility and Product Management

Tag: product management (Page 2 of 2)

Why “Yes” Doesn’t Scale

Everyone loves a “can do” attitude. “Yes, we can!” has become – even when stripped of any political connotations – the rallying call of an entire generation, empowered, driven, and enthusiastic. For a young startup, this type of optimism is a prerequisite. Pessimists would probably never embark on a dangerous journey into uncharted waters, let alone survive the trials and tribulations that are an integral part of bringing a new product to market. But as startups grow, …

Continue reading on ProductCraft (where this full post has been published)

The Evolution of Product Management

Product Management is a newer “function” and many companies don’t employ it from the beginning. Instead, it tends to emerge over time as companies start focusing on making their software products better. I’d like to describe a common pattern I’ve seen that shows how organizations often introduce Product and related functions in an Agile environment. Of course, not everyone will follow this pattern: the sequence may change or some may jump straight into later stages, but the main progressions is typically similar.

The starting point often looks like this:

“IT”/Technology is developing and operating software applications. Agile Product Owners (POs) exist, but they are typically part of the technology organization and often have less of a true Product background, but tend to have job titles like Business Analyst, etc.

As the organization doubles down on making the software products actual commercial products
and is ready to start emphasizing product as an actual craft and independent function of its own right, Product Management is introduced into the organization:

Continue reading

The Importance of Mental Models in Application Design

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:

Continue reading

Ease of Use

As I’m using different software products and applications lately, here’s a question I’ve been pondering: What makes an application intuitive and easy to use? (Beyond that, one could ask what makes an app “fun” to use, attractive, addictive, etc., but those are different topics of their own.) Let’s assume an application meets user needs via its built-in functionality, what’s the difference between being perceived as user-friendly vs. hard to use?

I’m not a trained UX or Product Management professional, but based on what I’ve been experiencing, I’d boil it down to this:

  • Predictability and
  • Discoverability.

Here’s what I mean by those terms:

Predictability

An application is predictable when the user can…

  • Understand how its features work – without relying on documentation or “Help”,
  • Intuitively predict how the application will react to user operations – without specialized background knowledge, and
  • Reach correct conclusions about how to go about meeting his needs through the provided functionality.

One of my theories is that many applications get designed by developers, not UX experts. (No offense to developers – I’m one myself and do design my own apps!) Developers think about functionality differently, often approach it from a technical perspective and they inherently know to much of the application and its design already and can’t put themselves in the shoes of a casual or new user without that background knowledge.

Other considerations to enhance predictability are:

  • Consistent use of UI elements, fonts, color schemes, iconography, screen layout, and naming conventions
  • Repeatable patterns
  • Consistent paradigms

Discoverability

High discoverability means that the features and functionality of an application can be easily discovered by the user – again without relying on documentation or help. The user will not be able to leverage and appreciate an application’s functionality if it is difficult for him to discover that it’s actually there. If functionality is hard to find or practically hidden, there’s a risk of user never finding it and getting frustrated because he can’t solve his need.

If an application is well instrumented, i.e. user interactions (e.g. time on page, mouse interactions, scrolling, entry and exit points, etc.) are tracked, logged and available to the application provider, interesting insights can be gained about which parts of the application, features, and controls are used and how often. This information is vital as it depicts how users actually use the application which may be quite different from how the designers intended it. It may also uncover screens or features that are barely ever used, maybe because of lack of discoverability.

The dark side of discoverability, which should obviously be avoided, is overloading the UI with menus, buttons, and controls, which could overwhelm the user. The art is exposing functionality in a thoughtful manner. One technique that could help may be to create layers of functionality, i.e. primary functions, which are easily visible and accessible directly from the UI, and secondary functions, which are still easily accessible, but maybe only via other UI elements (instead of being exposed directly). Example: Microsoft Word allows me to quickly change a paragraph style via a single click of a primary UI element while inserting a footnote requires a trip to the menu. Once again, a UX professional might help provide some much needed skills in this area (and provide a counterweight to us developer types).

Overall, I think more attention needs to be paid to how we design applications. I guess in the end, I’m making a case for either engaging people with the appropriate education and experience or at least being more deliberate about how we design our apps and look at them from the perspective of an outsider, not from the angle of a technical insider. More advanced practices like instrumentation & application analytics, user research, user observations, interviews etc. will certainly also be invaluable in enhancing our applications’ predictability and discoverability.

Lean StartUp in Action

startup logoThis week I had the opportunity to participate in an innovation event by my company called simply “StartUp” in which the we were able to really put into practice the principles of the Lean StartUp.

The roughly 150 participants were asked to come up with new products or even businesses and prepare a 1-minute pitch; no slides, no gimmicks, just talk. After 1 minute, the buzzer went off and we were cut off – no extensions. We had to cover problem/customer need, provide a sample scenario, how we’d solve it, and end with a catchy product/business name. I was one of the roughly 45 people who pitched their ideas and let me tell you – this was tough!

Then all the pitches were represented on post-its on the wall and each audience member got 3 sticky notes to vote. Then the top 22 pitches were selected and the audience members self-organized into teams of 3-7 people.

The next step was conducting empathy interviews with consumers / customers which included walking up to strangers and trying to engage them in a conversation about our idea. The objective was to learn as much as possible and validate target audience, what are the real problems people have, do we really understand the needs, etc. This was a humbling experience for many. While all were bright individuals with lots of subject matter and industry experience, in more than (I’m guessing) 40% of the cases, the initial understanding of the problem/need were anywhere from slightly off to way wrong – a humbling experience! Then we could either pivot and adjust our understanding of the problem space and our solution – or give up.

Then came experiments with prototypes, be it on paper or online.

We also had to articulate and flesh out the business case, e.g. size of the market, revenue models, cost, competitive landscape etc. to prove that our solution translated into a viable business.

In the end we had to make a final, 3-minute pitch to judges (plus 2-3 minutes of Q&A) who then evaluated our product or business ideas and finally selected the top concept. The winning team will be able to work on fully fleshing out their idea for the next 90 days with the end goal of seeking actual seed funding. Exciting stuff!

Here are some of the key learnings from this process:

  • More often than not, we don’t know what people really want and would use. This includes seasoned product managers.
  • You can’t just work from a desk/office and figure this stuff out. You have to talk to people in the real world. Then focus on listening.
  • It’s good to fail fast and pivot. The first idea will rarely be “the one”. Only validated, viable ideas create real business value. (See my other post on Business Agility.)
  • Small, cross-functional teams work. People with different backgrounds and skills form teams capable of incredible things and are more than the sum of the parts.
  • Short presentations are very hard. Focus on the essence and don’t overload on details. Make your key points and connect to the audience both through key facts and at an emotional level.
  • Despite the focus on the essence of things, tons of legwork is needed to get there. Saying less is harder than more.
  • Finding a viable, sustainable business idea is not trivial.

The Lean StartUp approach works! This event gave us the opportunity to act and feel like entrepreneurs – outside of the comfort zone of our regular jobs, without job titles, processes, and support from the outside world or the rest of our organizations. Equipped with just our ideas and laptops, we worked long hours to create something new from scratch in just 54 hours while competing with dozens of other ideas and teams.

This had been a very valuable experience. If you ever have the chance to do something similar – try it!

Business Agility

I think a lot of us dealing with Agile software development frameworks and practices on a regular basis have a good understanding of what it means to be “Agile” at that level. On the other end of the spectrum, there is “Business Agility” and that term is more amorphous and less understood. Below is my summary of what I believe the goal of Business Agility is as well as characteristics of organizations embodying Business Agility. Some of the definitions “out there” tend to be more lengthy, so I’m trying to keep it very succinct.

Goal

Business Agility aims to enable an organization to …Flexibility-Business

 

  • Respond quickly to emerging market needs and opportunities
  • Make critical decisions quickly
  • Reduce risk by testing hypotheses quickly, succeeding or failing fast
  • Innovate aggressively and often
  • Learn and evolve quickly based on short, frequent feedback loops

 

Characteristics

In my research, the following characteristics appear to occur most commonly in the context of Business Agility:

 

  • Focus on the customer
  • Self organization within small, cross-functional teams (development teams and beyond)
  • Decentralization of decision making
  • Empowerment
  • Adaptive and flexible
  • Experimentation and iteration on ideas (e.g. Lean StartUp approach)
  • Small batches and short planning horizons
  • Frequent delivery
  • Reduction of complexities and dependencies in favor of smaller, de-coupled autonomous units and architecture
  • Comfortable with risk, uncertainty and not having full, centralized organizational control
  • Shared purpose, vision, and/or values over detailed “processes”
  • View of the organization as “complex adaptive system

 

A number of these characteristics are rooted not in specific practices and techniques, but more in the overall company culture.
The notion of innovation I didn’t find mentioned all that often, but I took the liberty to add it because I think it’s important. Being adaptive and responding quickly to change are great, but they’re purely reactive and “outside in”. The concept of innovation is a proactive, “inside-out” effort, which in the end may be even more valuable in moving an organization and its products forward.

P.S.: After writing this post, a great article on the topic of Organizational Agility was published here.

Newer posts »