At a recent meeting with director of Product Management we were reviewing the Product Roadmap discuss the status of things. While reviewing one particular item he made a comment to the effect:
‘Wow, I remember when you guys started working on this feature. You seemed pretty much done after the first meeting. That was six months ago….'
I went onto to explain that he participated in one session (I was very happy he attended this meeting) to explore the problem and that we were very far from a good solution at that point. This really didn't matter and clearly he was frustrated and confused. The fact was that we had gone from that meeting and iterated the design twice based on user feedback before having a solution we were comfortable with. I realised that from his perspective once the user stories were started it was reasonable to expect some sort of user facing output in the near future. The reality was we when we started User Stories some issues were unknown which tended to spawn investigations and other User Stories, and so on …you get the picture. It seemed to me we spent a large time researching and not delivering . We needed another way to reduce this multiplication of Stories and do a better job in their preparation.
I also realized I had also done a poor job of explaining the process that we used. I have written about communication to build UX culture in organisations and this is something that needs to be done continually to be effective. Since this conversation, we have begun to integrate a slightly different process (or more accurately defining ‘a process’ ) into the Product Development cycle.
The process is based on two distinct phases - Discovery and Delivery - which although are drawn in a linear fashion are actually practiced together in loop that utilises feedback. The goal is to ask the right questions before we start developing so the development can be contained and more fluid.
Product Ideas
The start of this process is ideas.
In most organisations there is no shortage of ideas to consider for your product. In our situation we had way more ideas then we could ever realise. The key is to be clear what level of value each idea will bring and evaluate each very critically.
“Never found a company that said: We need [to] write down ideas, we probably won’t have any tomorrow or next week.”
In our situation ideas come from a few areas:
Product Managers - The Product Manager spends a lot of time visiting customers documenting the needs that they have. These are usually in the form of qualitative observations or specific complaints. Sometimes there is time to dive deeper into the user details of the issue, but not always. In general I view all PM ideas as assumptions and that need to be investigated or verified further. These ideas get added to a PM backlog (this will be a latter post).
User research - I am consistently amazed how many things I learn from meeting end users. This should be a large source of development ideas for your product. If you are not doing this - start.
Internally (engineers) - probably one of the best sources of ideas in my opinon. Engineers have a deep understanding of the technology which allows them to more easily imagine what the technology can achieve. As products become more complex, end users sometimes lack this knowledge, have difficulty considering what is possible.
The Competition - competitors are a good way to review how another company would choose to solve similar problem. This can include both user facing as well as technology solutions.
Discovery
The goal of Discovery is not necessarily to deliver any software. The goal of Discovery is to learn and to have conversations around some fundamental questions that will allow use to deliver better results. In our situation we were rushing into Delivery at the expense of doing the necessary Discovery.
During Discovery our goal is to answer some questions:
What problems are we trying to solve ?
What do people want to do that they cant do today ?
Are they willing to pay for a solution to this problem ?
What would a usable solution look like ?
Is this technically feasible ?
Problem Scope and Benefit - Defining what you’re going to solve
A clearly stated problem/opportunity is key for several reasons.
First, stating a problem clearly and concisely will allow you to define any holes in your thinking. It forces you to identify any assumptions, gaps in clarity and things that haven’t been validated. We found often that didn’t have all the pieces for any given particular problem definition. This forces a focussing of research and validation to clarify the problem boundaries. This was a large source of our User Story 'spawning' that was noted earlier.
Second, clearly defined problem boundaries nurture and encourage ideation which is important when we formulate your vision and Design. Whenever you present someone with a very clear problem the natural response is to start mentally picturing what a solution looks like.
It is important in this scope to link this problem back to the business value.
Some questions I usually like to discuss are:
How will solving this problem add business business value ?
What effect do we aim to achieve ? How will be measure this ?
How will solving this problem integrate into our overall strategy ?
Tools to consider:
I facilitate these discussions using a couple methods with good results. The Experience canvas and Impact Mapping are good for the strategic vision, while the Product Box exercise is good for product specific goals.
Understanding the User
Use discussions with users and customers to gain more insight into how they use your product and what they want to achieve. In my opinion, this will be the single most valuable thing you can do to develop the UX or your solution. I have mentioned the value of doing User Research together with Product Management but it can beneficial for most anyone involved in the development process. Within our team we perform and combination of ‘contextual interviewing’ to discover new product areas as well as formalised user testing to evaluate specific features.
Tools to consider:
Jobs to Be Done - Since our products are Enterprise oriented there are some fairly distinct user scenarios that people follow. I have found the Job to Be Done model quite helpful in analysing these scenarios. I am a supporter and have been using some nice JTBD interview cards that have been handy when conducting Contextual Interviews to focus on the Jobs. I have found the identifying the major Job then breaking this down to small Job tasks blends very nicely into my next favorite tool - User Story Mapping
Story Mapping - I have written about the value of using Story Mapping before. I cant express enough what an effective tool this has been for us. By mapping how user work today you get a much better idea of the problem you are trying to solve. From a solution perspective, It has allowed us to a get much better picture of the entire solution as well as identify many holes in our thinking. Story Mapping has allowed us to design a high level conceptual model that can effectively fully support the more detailed feature designs.
Envision a Solution
At this point you’ve determined what problem you are trying to solve, why you’re building this from a business perspective, and you have investigated users and customers so you know what their world looks like. The next step is to to imagine the future — to envision the solution and how your target customers and users will make use of it. These step also blends well into the result of the Story Mapping and allows to take this Map and refine it further.
The most effective tool for this is Design Studio. We have been using Design Studio consistently for the last three years with three development groups. This has proven very successful and I have written about it a few times here and here.
An important dimension of Design Studio process is the engineering validation. Once of the advantages of having developers participate is you get an sort of built-in ‘will this work’ validation. Even still, I think there is a value to have a part of the Design Studio that includes a ‘what if’ session. You’ve imagined the solution from a user’s perspective, and visualised the experience. These ‘what-if’ session allow the entire team to discuss what’s going on underneath the user interface. During these discussion talk about business rules, data validation, and tricky backend systems or services you’ll need to connect with. This is especially important when you work on a complex platform with a high level of product interaction. In or situation we have had to include other people from different parts of the platform.
Minimise and make a Plan
At this point there you have a reasonably good solution that has been discussed and understood technically. The key here is to divide the implementation into small enough pieces that can deliver value and at the same time be verified. For our organisation we are lucky and deliver things continuously, so getting value and user feedback is a bit easier. The goal is to minimise unecessary work so now is the time to priortise ruthlessly and reduce things. An important dimension to this is to communicate this plan to other stakeholders. This will allow them to understand the situation and manage expectations (which wasn't done in our situation).
The emphasis in the Discovery part of the diagram is a lot from the UX side of things and we have a large role to play, both in implementation and leadership.
As Jeff Patton says:
“UX work is mostly about discovery, agile [development] work is mostly about delivery. Two worlds – both concerns are necessary. Discovery never stop. And, discovery without delivery isn’t very valuable”
Delivery and Delivery need to work together and each organisation has their own way of doing development.
Once I have some time to use this model in practice I will follow-up with some thoughts on how Discovery and Delivery can work together.
Until then. Good luck.
Credits: Large thanks to Jeff Patton, Kate Rutter. Their ideas have been the inspiration and foundation for this post.