VC, POC, MVP, and Other Related Acronyms

I spent/invested some time in a past life supporting technology projects for the military. I learned that they use a ton of acronyms (LPTA, IDIQ, C4ISR, etc.), but the Armed Forces compares nothing to the society we live in today, in the acronym arena that is. The following excerpt is simply some things I have noticed in the App Dev/Scrum arena, so I hope it doesn’t make you LOL (at me), SMH (about my opinions), or even leave an OMG in the comments section. Scrum works well with acronyms too, and here is why:

VC – Venture Capitalist

 M&A (mergers & acquisitions) is becoming the new norm for an organization’s growth - and before I get carried away and come across like someone who is involved/is well-versed in these major transactions; for the record, I am not. I just read a lot about all the MnA going on, and see such articles on the rise.  The “A” part usually requires a rock-solid product, business plan, service, or idea to even draw attention from a Venture Capitalist, let alone, a purchase/investment. Since I live in the software world, what do you need to draw attention from a VC? Of course a very mature SaaS platform will draw attention, but what about the new guy with the fresh idea? 

POC – Proof of Concept

If the end-goal is to take an idea, attract investors, and inevitably end up capturing funds to grow your app, what is it you really need in a POC? It doesn’t make much sense (unless you have deep pockets) to construct your entire app, as we don’t even know if anyone wants it/will buy it yet! For the new guy, a great idea is a good start, but we all know funds are (usually) limited, so how do you position yourself to grab the attention of a VC, but still remain within your budget? Get a MVP.

MVP – Minimal Viable Product

MVP to me reads Mike Schmidt; best 3rd baseman to ever play the game. However, if you are a Scrum Fellow, MVP means something completely different. If you are not familiar with “MVP” in Scrum terms, it is the bare-bones, least amount of features necessary to get a product out the door, but still have a highly functional app. In a Story Mapping session, a Scrum expert will ask all of the right questions of the Product Owner (client/customer), uncover all of the Personas/users of the software, and collectively unmask all of the necessary features and workflow for an app. The beauty of this sticky-note process is that we get to the core of WHAT YOU REALLY NEED. Whether it is mapping out a full-fledged software solution, or a POC, the process works really well. For the new guy, with a great idea that is bound to be beaten up by a ton of VC’s, a scrubbed-down MVP can give you something to show. Better yet, the sophisticated Scrum Backlog (future plans/requirements/features) you bring along with you, coupled with your skeleton app, can help seal the deal.

CADT - Clearly Agile Does This

Clearly Agile is small, but we pack a big punch. We have recognized a major opportunity in the POC/VC/MVP spectrum. There are so many great software ideas in our marketplace today, but unfortunately the scale is tipped; and those good ideas outweigh resources and funding. That is where our expertise in establishing a MVP comes in handy. No matter the size of the endeavor, we insist on one thing, and that is to first have a Story Mapping session. Prior to price quoting, and especially development, this discovery period is essential. This process is also useful, no matter how great the initial idea is, to fill in the gaps, uncovering features the Product Owner hadn’t even thought of. Once all of the Users and Features are sharpie’d on to stickies, we can then start to prioritize features by Business Value, Importance, and Development Effort.

If a particular client is not quite ready to do a full build, we can continue the whittling-down of the MVP, allowing us to adhere to any timeline or budget constraints. What is the minimal viable POC that we can ship out, using the least amount of time and effort possible, but still grab the attention of a VC? This is where our Scrum Process really comes in handy. With our requirements/story/feature-slicing capabilities, coupled with iterative releases, our customer’s (and therefore VC’s) can see/touch/play with/use/interact with real live software every two weeks. When the max budget for a POC is met, we stop development, but provide our customers with a functioning app, and detailed Backlog of all of the features that are to come.

This has proven to work out very nicely. We help a customer who has a good idea, enhance that idea and uncover new possibilities, all the while working with them to give them a partially-finished, but concrete example of what their app will do. When they pack their work satchel with a laptop (to show their new shiny app off), their detailed backlog (to demonstrate what is next and where the product is heading), and a smile, VC’s are much more apt to listen (and write checks).

Any feedback on my thoughts are welcome, even if they are LOL, SMH, or OMG. Thanks for reading.