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.
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:
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.
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.