We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.

Deploy Decision Visualizations Like a Lean Startup

Originally published July 30, 2012

Successful companies thrive on their ability to make good decisions, quickly. Unfortunately, most business intelligence projects move slowly. Several lean startup principles1 can help you reverse the status-quo, set new performance levels, and be a change-agent. Remember, as a practitioner of Decision Visualization – Be decision-driven, supported by data and bold design.

The cornerstone of working lean is to learn and apply the learning as fast as possible. Sounds simple enough. Here's what you do:

  1. Test a hypothesis

  2. Build a minimum viable product (prototype)

  3. Release in small batches
However, business intelligence organizations are structured exactly OPPOSITE of the lean model:
  1. Define every requirement up front

  2. Build without collecting feedback

  3. Only deliver "complete" solutions
Picture your team as a startup company that wants customers using (and buying) their product ASAP. The business intelligence community must work with the exact same mind-set to help their companies gain a competitive edge.

Test a Hypothesis

Always begin by clearly understanding the decision your "customer" wants to make. A business intelligence premise is that if you give someone the right information, they can/will be able to take an action. How often do reports go unused or not acted upon in your organization? Doesn’t that frustrate you? Therefore, you must test the following hypothesis at each step of your project to ensure your work is directly tied into the needs of the organization, "They will take action on the decision, given the appropriate data in a usable form."

Address one decision at a time; you don’t need an exhaustive list to get started. When you ask someone what decision they are trying to make, they typically they respond with wanting to know about data. To flush out the decision, here is the type of discussion you should lead:

You: What decision are you trying to make?
Customer: What were our sales in each region last month?
You: If you knew that information, what would you do?
Customer: I could tell each salesperson if they need to sell more.
You: How would you decide if they are selling enough?
Customer: Well, first I would need to compare sales to targets.
You: That makes sense. How far off target gets you concerned?
Customer: More than 5% behind could be a problem.
You: What else do you need?
Customer: If they trended down the last three months.
You: So, is the decision: "Do I need to work with the salesperson to increase sales of specific products?"
Customer: Yes, I agree. This was really helpful!
Once you know the decision, it is helpful to frame the supporting data as a results statement – and validate it with your customer, "The salesperson must be at least 5% behind target and trending down the last three months. Is that correct?" The simple results statement is incredibly powerful. If the criteria are not met, they do not need to think about taking further action. All the noise from irrelevant data is cleared away. I AM NOT saying someone can make a final decision with this information alone; rather, it indicates an action may be necessary. Also, someone will likely conduct a more detailed analysis based on the observed results.

You have just experienced (in short form), the first two steps of what I call DRAW-ON™. The full six steps together deliver a complete solution to make the decision – or not. The framework incorporates lean product concepts and provides a consistent approach for teams to collaborate around business intelligence projects. It’s a dramatic shift from most business intelligence work.

Figure 1: The DRAW-ON™ Toolset © 2012 DecisionViz (mouse over image to enlarge)

Build a Minimum Viable Product Prototype

The decision and results statements are initial requirements for your visualization and building a minimum viable product (MVP). The MVP is the simplest means to collect feedback from customers and refine until your customer agrees with the hypothesis: "They will take action on the decision, given the appropriate data in a usable form." By “minimum,” the MVP is not about trying to deliver a final product (visualization) with a limited number of features; although, you would not want to deliver more than needed. ** If you were truly a startup, the MVP would test the viability of your business idea. For our work in visualization, it’s easier to think of it as a refining cycle.

You don’t need design software to build the prototype. Let me say it another way – don’t use design software. Head up to a whiteboard with a black marker. Otherwise, get paper and a black Sharpie™ – email me feedback on this article or a story about how you have improved visualization work and I'll ship you one. Most clients I work with initially think this rudimentary approach is not worthwhile. The basis of working lean is to move quickly, and they soon realize that choosing colors or making detailed designs is distracting and time consuming (you will find it hard to write any level of detail with a thick marker).

Within 30 minutes, put your energy into volume and variation of ideas. It's only important to rough out the visualizations, continue the discussion, and get feedback. Ask everyone for his or her initial reactions and interpretations; first-impressions are key. For example, this sketch might start a conversation around what decision is needed if the salesperson is above target but trending down for three months (i.e., Product 1); that should turn out to be more critical that the original decision you are testing!
  • Decision: "Do I need to work with the salesperson to increase sales of specific products?"

  • Results Statement: "The salesperson must be at least 5% behind target and trending down the last three months.”
Figure 2: Example MVP (performed with black Sharpie™) © 2012 DecisionViz
(mouse over image to enlarge)

There are phone apps to snap pictures of the whiteboard and stitch the images together. If you work on paper, stick with one idea per page so you can swap sections to create the best story without having to redraft all other elements. Your finished product may, of course, combine ideas onto a single dashboard/screen.

In whatever form you capture the prototype, you will need to make a final version, clean and legible, along with notes explaining interactions, legends, etc. You can just make neater drawings or use computer software (PowerPoint, KeyNote, Visio, OmniGraphSketcher, …). You might find that recording concepts and operating intent is enough; the detailed requirements will be determined during development as the team works collaboratively. Keep thinking and acting lean.

Release in Small Batches

The practice of delivering a “complete” set of visualization solutions just doesn’t work – it never really did. For a long time, people have felt secure using this approach. However, if it takes a few months, or even one month, to write “all” the requirements and then develop, there is a good chance the requirements will have changed. All the while, your customers wait helplessly without any visualizations. Can you see how delivering more frequent, smaller releases creates opportunities to move the business forward by making decisions sooner? Doesn’t it make sense to receive and incorporate feedback from real-world use before building out too far?

Everyone involved with the business intelligence solution, most importantly your customer, must agree to work in this model or it doesn’t work. People will be a bit unnerved because they are comfortable in the current long-cycle model; they know (or think they know) how the project is going to turn out. Shifting to a small-release model will initially generate feelings of uncertainty and doubt. It seems ad hoc when in fact there is a solid process. After a few releases, people will begin to see the impact. You have to help the organization cope with withdrawal as they rid themselves of old dependencies. You can ease the transition by encouraging collaboration and reinforcing the benefits of small batches over detailed requirements and complete solutions.
  • Keep a list of all decisions/results hypotheses that have been tested or need to be tested.

  • Meet once a week to review and reprioritize the list.

  • Be okay with stopping work and switching to something that becomes more important.

  • Fix what’s broken right away.

  • Test hypotheses in parallel with developing finished releases.

  • Create rough deadlines for each release; it’s helpful to have a target.

  • Make everyone responsible for QA. Don’t put it all on development’s shoulders.

  • Treat enhancements as a new prototype to test; don’t just add them in.

How to Get Started

Although everything in this article may be disruptive to your embedded ways of working, when moving your team in a new direction, it’s often helpful to minimize disruptions. I recommend applying these ideas to a small, new project. Stay out of the spotlight until you try these ideas and work through the particulars of your organization. If you attempt to update an existing project, it will be hard to switch end users from what’s currently available because they will feel like you are providing less capability (fewer reports/ dashboards/ charts/ …) – even though by following DRAW-ON and lean techniques you will be providing HIGHER capability toward making decisions.

The dramatic changes in the role of visualization call for an equally dramatic rethinking of how to deliver exceptional products to customers. The strategy of Decision Visualization is the foundation; the DRAW-ON toolset and lean techniques are execution tactics. Continuing to see your work as a business will lead you in new directions to unlock the value residing in data.

Have you applied ideas from startups or other standard business practices to visualization? If so, I’d love to hear about it! You can reach me by email at Lee@DecisionViz.com.

End Note:
  1. The Lean Startup by Eric Ries is a popular book on working lean. You can find good material at http://theleanstartup.com/.

  • Lee FeinbergLee Feinberg
    Lee is the Founder of DecisionViz, a management consultancy that helps companies “escape the legacy of reporting data by transforming complex data into simple pictures for making decisions.” Ten years ago, working with companies generating large amounts of Internet data, Lee realized that visualization would be a disruptive capability. Clients such as IBM, Ford, and Nokia have used his Decision Visualization™ business strategy and DRAW-ON™ visualization process to make data actionable. Industry leaders frequently ask Lee to address domestic and international audiences, most recently including O'Reilly Media Strata, Tableau Software European and North American Customer Conferences, TDWI, Data Modeling Zone, CBS Interactive, and WARC.  He is also the founder of the NJ and NY Tableau Software User Groups. Prior to founding DecisionViz, Lee joined Nokia in 2009 with the vision of “making data a part of every conversation.” His team launched data visualization services, providing 1000+ employees access to dashboards and analysis, under the credo "running business intelligence like a business." At Razorfish, Lee established an analytics management practice for the Ford Motor Company. At Digitas, Lee served on IBM’s corporate task force to define online metrics standards and introduced early interactive visualization technology.  Lee received a B.S. and M.S. from Cornell University and holds a U.S. Patent for a PC-telephone interface.  He is a member of the Cornell Entrepreneur Network and the Sandler Sales Institute. 

    Website: DecisionViz
    Email: Lee@DecisionViz.com
    Twitter: @DecisionViz
    LinkedIn: www.linkedin.com/in/leefeinberg

Recent articles by Lee Feinberg



Want to post a comment? Login or become a member today!

Posted August 16, 2012 by Lee Feinberg Lee@DecisionViz.com


Thanks for sharing your thoughts and I am glad these ideas can help you!

Yes, simplicity is certainly needed at many levels these days.  When it comes to communicating, especially complex data, simple -- not necessarily simplistic -- is key.



Be decision-driven, supported by data and bold design (TM)

Is this comment inappropriate? Click here to flag this comment.

Posted August 14, 2012 by Gregory Lewandowski

Another well done posting Lee; I continually find your articles informative!! This was a great reminder to embrace the beauty of simplicity and recognize some of the signs of organizational over-complication.

Love the idea of treating things like a start-up, and working lean!! There is alot of wisdom in this approach, on a number of levels!!

Looking forward to more...

Is this comment inappropriate? Click here to flag this comment.