The Art of Building Rapid and Valuable Proof of Concepts (POC)

Clients and stakeholders want results. They want assurances that their investment is well spent and they’re building the right product. The 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 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.

  1. 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.
  2. 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, use mock data.
  3. Estimate Accuracy – 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.
  4. 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.
  5. 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 todo 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 email from the client, you generate this first feature list:

  • A user can login or register with google, Facebook, and email
  • 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. Now let’s estimate and prioritize the rest.

  • [2] A user can view a list of tasks
  • [1] A user can filter/search the list of tasks
  • [1] A user can add a task. This should be done in a modal with the task list in the back.
  • [1] A user can name a task
  • [1] A user can tag a task with a color
  • [2] A user can “manage” the tasks list which then allows the user to select one of more task to be deleted.
  • [1] A user can set a reminder date for a task
  • [3] A user can enter a location for a task

________________________________________________

  • [1] A user can share a task. The data to share is in text form
  • [3] A User can add an image (captured or selected from the camera roll)
  • [3] A user can add a video (captured or selected from the camera roll)
  • [5] A user can edit the length of a captured video
  • [5] 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 ok 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, 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 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. 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 something that can prove the concept.

Matt Sich

Matt Sich

Software Engineer

Matt Sich is a Software Engineer at 3Pillar Global. He works on our Seal Team, a small, technology-agnostic team that handles short-term projects with quick turnarounds using mostly one week sprints. His projects usually have heavy use of AngularJS and Java with Spring Frameworks. Before joining the 3Pillar team full-time, Matt interned with us one summer while in college. During the internship, he developed and designed iOS apps. Matt received a B.S. in Computer Science from the Franciscan University of Steubenville.

Leave a Reply

Related Posts

Customer Segmentation Based on RFM Introduction Retail stores constantly gather purchase history and demographic data from their customers. Machine learning algorithms could use this d...
Take 3, Scene 26: The Value of Retrospectives On this episode of Take 3, Jonathan Rivers and Alexis Ireland discuss the lessons that Agile development teams can learn when they have retrospectives...
I Want My MTV: Minimize Time to Value As a former MTV staffer from back in the music video heyday, I was pleasantly surprised to hear members of our Product Strategy & Design team emph...
Take 3, Scene 16: The Truth Behind Scope Creep On this episode of Take 3, we discuss the notion of scope creep - what it means for development teams and whether it exists at all. Jessica Hall and A...
Microservice & Serverless Architectures – Is Eith... On this episode of Take 3, we explore microservices and serverless architectures - what they are, why microservices have gained so much in popularity ...

SUBSCRIBE TODAY


Sign up today to receive our monthly product development tips newsletter.