Software Engineering, Project Management, and Effectiveness
The Rapid Research Method is a way to speed up your product research. It’s also a way to speed up ramp up time when you are leaning a new domain. The Rapid Research Method is also a key for rapid innovation and rapid product design and development. Lastly, the Rapid Research Method is also a great way to map out a space and perform competitive assessments.
One of the challenges with product development is doing effective research for your product design to make sure you have the right map of the pains and needs, the top concerns, and the key desired outcomes. Another challenge is actually making this information actionable and simple to share.
I’ve had the benefit of driving several projects end-to-end, so I’ve been through the research and exploration stage multiple times. I’ve learned a lot of tricks for speeding up research and making it more effective. I’ve had to use these techniques to play catch up in various domains from application architecture to security and performance, to even the cloud. They work.
I’m going to share a few techniques in this post. Collectively, I”ll refer to using them as the Rapid Research Method. It’s the approach I’ve used for many, many projects over many years, and as a way to perform competitive assessments.
What’s important about the techniques is that they make it easy to rapidly organize and share vast amounts of information in an actionable way. Looking back, one of the big surprises for me is how just about any domain can be broken down into questions and tasks. If you know the questions that people ask and the tasks they need to perform, you’ve effectively mapped out the most important information within that domain. This helps you prioritize all the rest of the information, such as concepts, principles, patterns, and practices. Another way to look at it is that all the information is either going to be action or reference. For example, a checklist would be actionable, while a whitepaper on a key topic, tends to be conceptual.
Software, like an information product, tends to suffer from information management problems. It’s tough to share “castles in the mind.” Then there is the people factor. Not everybody can slice and dice information the same way, or with the same skill. The real issue though is sharing “state.” The problem with research is that it’s like climbing a mountain. How quickly can you get others to make it up the mountain, after you? What sort of trail or spikes can you leave along the way? That’s where these research tools that I’m about to share come into play. They help you not only get you and your teammates up the mountain faster, but they leave a trail that others can follow.
The approach is fairly easy. It involves creating simple lists. The power comes from how you create and share these lists. It’s actually the information architecture of the research that unleashes the power of your research. The single best thing you can do with your research is produce output that can easily be used by others, so that you can easily bring in more brains on the problem. When everybody can see the lay of the land, it’s easier for people to find a faster way forward, get resourceful and solve problems.
Here is the approach in a nutshell:
I’ve often said that any problem domain can quickly be broken down into questions and tasks and address 80% of what matters. That little rule of thumb has served me well, time and again. I never get stuck when I’m figuring out a new domain. I always go back to the basics. The real race is to find the fastest way to get the questions and tasks down on paper in a shared way that others can contribute, review, and prioritize.
You can browse the examples below to see what these question lists, task lists, hot spots/frame, and user stories look like.
“Hot Spots” are simply the key categories or areas of focus. They represent the categories that are key choice points. They are actionable. They are “Hot Spots” because they are 80% of where the action is. They are the 20% of the domain that accounts for 80% of the activity. I use “Hot Spots” as a way to slice a domain down to size and quickly get to what counts. Each “Hot Spots” represents an area that is either a key opportunity or a key pain point. The “Hot Spots” are a great way to organize actionable information such as principles, patterns, and practices.
The Frame is simply a lens for looking at a problem. It’s what’s in the picture and what’s out. How you frame a problem domain can either simplify the problem space, or make it more complex. When you frame the problem space well, it makes it easier to act on it. It makes it easier to identify opportunities for innovation. It makes it easier to research the problem space with better focus. Focus is your friend.
The problem is that you usually don’t know the key areas up front. Framing out the space is part of the challenge and it’s part of the by-product of your research. What I’ve found is that when you start to collect questions and tasks, that “Hot Spots” start to emerge. You will quickly start to see patterns and things will naturally start to cluster. This collection of “Hot Spots” becomes the backbone for your frame. Rather than be complete, it’s about being effective. You can use the 80/20 rule to your advantage here, which is how you both gain speed, but also amplify your impact by focusing on the highest priorities.
This is a simple example of a frame using security Hot Spots. By using this collection of Hot Spots, it was very easy to collect questions and tasks within the security domain. It was also easy to walk different technologies and evaluate their security profile. We also used the frame to quickly gather and organize threats, attacks, vulnerabilities, and countermeasures. Organizing the information using this frame made it more actionable, and it made it a lot easier to deal with information overload.
Security Frame with Hot Spots
How does your application handle and protect user sessions? A session refers to a series of related interactions between a user and your Web application.
A “Question List” is simply a list of the key questions that people ask. You can find the key questions through surveys, going through forums, looking through blogs, and through hands on experience. Hands on experience helps you build empathy for what really matters, which will be essential when you are trying to rank, rate, and sort your list. It also helps to organize your questions into “Hot Spot” areas or buckets.
Architectural Frame Questions List
Authentication and Authorization
Caching and State
Concurrency and Transactions
Coupling and Cohesion
Logging and Instrumentation
A “Task List” is simply a list of the tasks that users perform within a domain. I find it helpful to use the language “How To.” This forces people to think in terms of goals. Sometimes it’s helpful to know the goal. Sometimes it’s more helpful to know the specific tasks. When you need to up-level it, simply ask “What are you trying to accomplish?” When you need to drop down a notch, simply ask, “What are you trying to do?” You can collect tasks from users through interviews, surveys, etc. Again, I find that hands-on is one of the best ways to really build empathy for the pains and needs. The real power comes from transforming from the problem side (the pains and needs), to the solution side (the specific goal or task that would address the pain or need.)
Architectural Frame Tasks List
I’ve found it especially helpful to organize massive lists of tasks into simple two-column tables. This creates a nice view that makes it very easy to prioritize, cut, or elaborate, in a fast and simple way. You can color code your lists. You can bubble key things to the top. You can make whitespace where you need it. You can group your tasks under sub-items within a row. The choices are endless, but the two-column tables does make dealing with massive mounds of information a breeze. The way it compacts and frames information makes scanning very easy, which is important when you are trying to get the “bird’s-eye view.”
One of the most powerful techniques I use to rapidly gather user requirements is user stories. I find that capturing user stories with the language, “As a user, I need to” .. or “As a user, I want to …” really helps add context and clarity, while keeping it amazingly simple. I also find that organizing the user stories by Hot Spots helps go a long way, especially when you are dealing with a large amount of information. Below is an example where I was collecting user stories to rapidly figure out the top concerns of business leaders and Enterprise Architects when it comes to cloud computing.
The beauty is that when you capture the user stories well, it is very easy to deal with both timeless stories and timely ones. In this particular example, even though it’s a few years old, you can see that the top issues that it exposes are alive and well. One additional point on this example is that I used another information pattern. I call it the “View More” pattern. I use it to bubble up the short-list and then push the rest of the list below the “View More …” heading. It’s highly effective for organizing very large information sets, especially if you alphabetize the list.
User Stories for Cloud Enterprise Strategy
Cloud Enterprise Strategy Scenarios Map
Awareness / Education
Governance and Regulation
Service Levels / Quality of Service