August 14, 2017
The Art of Building Rapid (and Valuable) Proofs of Concept
Clients and stakeholders want results. They want assurances that their investment is well spent and they're building the right product. The software development industry has done well to mitigate project reception failure by implementing pre-engineering practices such as user testing, competitor research, and other due diligence. These work, but they can be improved upon by the creation of a working proof of concept (POC).
There are five factors that dictate a successful POC, and they demand a strict acceptance of agile principles.
- Time - A project deadline or business need may dictate that a POC be completed by a certain date. More often than not, only a few days are allocated.
- Priority - A project must be viewed from a business perspective. What is the one feature that would prove the product to a stakeholder? Now break down that feature into tasks and prioritize it. At what point down that list do the tasks become extra and won't be missed in the POC? When developing, you must prioritize the tasks that are most visible to a user. Do not be bogged down by infrastructure or hidden subtasks. For example: if you need an API in the finished product, use mock data for the POC.
- Estimate Accurately - Be prudent. Do not over promise. If finishing in the given time is not possible, or even questionable, prioritize the tasks and set the expectation that the items at the bottom of the list may not make it into the POC.
- Quality - Just because time may be short does not excuse poor code. Building POCs provides a perfect opportunity to hone your skill and coding practices. In most cases, the POC will be used as a foundation upon which the greater project will be built; therefore, future project success depends on it.
- Acceptance of change - Value responding to change over following a plan. Don’t simply be open to change, welcome it. View the project from the business perspective. If a change is introduced, there’s likely a good reason for it.
Let's consider a scenario and apply these key factors. Along the way we'll intentionally introduce common issues and find solutions to overcome them.
It's Monday and there's a meeting with a potential investor on Friday. You are asked to build a POC for a to-do app in 5 days. The client specifies that it must be built as native iOS and Android apps. Designs for the app are provided. Based on an initial conversation with the client, you generate this first feature list:
- A user can login with Google or Facebook, or register for a new account with their email address and a password
- A user can open a settings page
- A user can leave feedback in settings
- A user can logout from settings
- A user can view the app version number in settings
- A user can view a list of tasks
- A user can add a task. This should be done in a modal with the task list in the back.
- A user can name a task
- A user can set a reminder date for a task
- A user can enter a location for a task
- A user can tag a task with a color
- A user can add an image (captured or selected from the camera roll)
- A user can add a video (captured or selected from the camera roll)
- A user can edit the length of a captured video
- A user can crop and add filters to a captured image
- A user can "manage" the tasks list which then allows the user to select one of more task to be deleted.
- A user can share a task. The data to share is in text form
- A user can filter/search the list of tasks
Quite the list for a five day POC. The time limit is set in stone, therefore we must prioritize the features. The most important feature from both the user's and client’s perspective is the list of tasks. We don't need both an Android and iOS app for this POC. The client has an iPhone, so let's build the POC on iOS. Even so, it's unlikely that it will be completed in five days. Let's cut out the authentication and the settings page, as those are not part of the primary feature set. Now let's estimate and prioritize the rest.
-  A user can view a list of tasks
-  A user can filter/search the list of tasks
-  A user can add a task. This should be done in a modal with the task list in the back.
-  A user can name a task
-  A user can tag a task with a color
-  A user can "manage" the tasks list which then allows the user to select one of more task to be deleted.
-  A user can set a reminder date for a task
-  A user can enter a location for a task
-  A user can share a task. The data to share is in text form
-  A User can add an image (captured or selected from the camera roll)
-  A user can add a video (captured or selected from the camera roll)
-  A user can edit the length of a captured video
-  A user can crop and add filters to a captured image
Everything above the line is absolutely required for a successful demo. We should do our best to complete the remaining tasks, but it will not ruin the demo if we aren't able to.
After presenting this plan to the client, you receive push back. The client is okay with an iOS version only for the demo but doesn't understand why we cut out the other features. Because of this, we present the numbers. Based on previous work, let's assume you know that you can do 13 story points in a week. The resulting code from a 13 story point week has a high quality of code and includes tests (unit, integration, and UI where applicable). With that in hand, you can then present those numbers to the client. We have 12 story points above the line in the feature list and we know we can do 13. Be open to re-prioritizing tasks. Listen to the client's concerns and substantiate your position with data when possible.
Now that a plan is set, get started. Don't delay the first step. If you're unsure of the first step, start with the item at the top of the priority list. Focus on getting a version of the app to the client by the third day. Doing so will let them provide you with valuable feedback. A version on day three may only have the top four tasks, but it is still valuable to the client.
Let's throw a wrench into the plan. On Wednesday (day 3), you provide a version of the app and the client realizes that something is missing. In order for the demo to be successful, you need to add the ability to star/favorite tasks. You estimate 1 story point for this addition. Remember, change is good. You must expect it and be willing to accept it. This open mindset is crucial to successfully building valuable POCs. With that in mind, you must make a trade. What item currently in the list of required features can be swapped for the star feature? After speaking to the client, it is determined that the color tagging can be de-prioritized.
At this point, you would most likely be ready with the app on Friday and may even complete a few extra features.
There are two main takeaways here: despite a lack of time, a middle ground can be found and, as an engineer, viewing the product from a business and user perspective helps drive value. If a client or stakeholder needs something done fast, you can often negotiate, set expectations, and deliver a proof of concept that will pave the way for learning and future development.