By software consulting standards, Unspace Interactive is a small boutique. As a byproduct of our small size and close relationship with the startup community, more than half of the Request for Proposals1 we consider are for what I call “Software that Powers the Startup.”
The typical RFP for Software that Powers the Startup is from an entrepreneur that wishes to launch a web-based technology business. The request is that we develop a plan to design and build the software that will make the startup dream a reality. In twelve weeks, without fail :)
While the RFPs vary in sophistication from an email with some ideas all the way to elaborate screen mockups created in Photoshop, they nearly all omit vital requirements that define critical business functionality. I see this RFP “blind spot” so often that I have developed a standard question to ask, one that invariably opens a massive can of worms.
What is this question I ask?
“Imagine your software has a dashboard, a single page that shows you at a glance the most important information you need to know to do your job as the company President. What’s on your dashboard?”
focus
If you log into Facebook, your “home” view is a kind of dashboard. There is only so much screen real estate, and you only have so much attention. Thus, the design of the Facebook home page is a statement about what Facebook the company believes is important to you.
Likewise, a business dashboard is a statement about what the entrepreneur believes is important to the success of the business. There is only so much space, so much time to develop dashboard features, and the entrepreneur only has so much time to look at the dashboard and figure out what is going on with his business.
The reason to ask an entrepreneur to describe his dashboard is that it forces him to think through and articulate how he plans to run his business.2
two bicycle shops
Imagine two nearly identical RFPs for online bicycle shops. One is for BMX bikes, one for Commuters. Both describe online shopping sites where customers can browse through models from various manufacturers, compare features and prices, and even customize the bike they want before buying it online and having it shipped to their door.
Given two nearly identical RFPs, should we end up with two nearly identical proposals? Almost certainly not. Although both businesses may appear almost identical to the bike-shopping user, they may be radically different to their respective entrepreneurs.
Perhaps our BMX company relies on optimizing operations. The founder’s business strategy is to maximize his cash flow. He cares deeply about metrics such as his inventory turnover. He wants to be alerted to stock that is aging so he can cut its price and move it quickly.
Our Commuter store may rely on optimizing marketing. The founder’s strategy is to maximize margins. She cares deeply about metrics such as average revenue per customer broken down by source. She wants to monitor her product profitability and advertising effectiveness.
To do a good job of proposing a project for our respective entrepreneurs, we would need need to understand these important differences. Asking about the dashboard kick-starts that conversation.
happy endings
Whether we’ve ended up building a dashboard into the initial release or not, I can say with confidence that every investigation that began with the question “What’s on your dashboard” has ended well for the client and for Unspace. At some point in the future I may be handed an RFP for Software that Powers the Startup with substantial attention paid to the business’s operational focus.
Until then, I expect to go on asking this question.
-
A Request for Proposal (or “RFP”) describes a piece of software as the client sees it in his mind. The RFP purports to provide all of the information a consultant or custom programming team needs to propose a project to design and implement the software.↩
-
It is not necessary to ask this exact question. You could describe a notification system and ask, “When should you be notified?” RFPs often ask for flexible reporting systems: Instead of deferring the details until later, you could also spend time on the management reports up front. There are many ways to get to the same place, the important thing is to dive into how the entrepreneur plans to manage his business, not just how he sees the software from the end user’s perspective.↩