How to Apply the Systems and Resources driven framework to your Startup — Part 2 of 3
By: Vikas Lal Sahita
Tags: Startup, Business Strategy, Strategy, Startup Lessons, Strategy Execution

How to Apply the Systems and Resources driven framework to your Startup — Part 2 of 3 Vikas Lal Sahita May 22·5 min read

Thank you for staying the course and making it this far. Keep going for the practical how-to stuff.

Now we’re getting to answer your question on how do we apply all your new learning to your own startup. Well, honestly, every startup is different, however there are some common denominators that connect them. We’re going to try and focus on solutions to those common constraints or problems by applying our theory of systems and resources.

Before proceeding, if you haven’t read the first part, I strongly recommend that you do, since without that preface, the below would not be easily understood or even make any sense whatsoever.

Practical steps to apply our model to your startup :

(1) Once you have an initial hypothesis of what you want to build, try and understand what resources you are importing and what is their cost, in terms of time, money and user experience, to you, and how that impacts the user experience in terms of the user’s time and money. Doing this sounds easy, but it is painstakingly difficult and can unnerve the best of dev’s and engineers.

This most important schematic in a startup, is to identity under-utilized or unused but useful resources from other systems, importing and processing these resources in a way (aggregating, augmenting, algorithmizing) to make them meaningful for your users.

(2) The technical resources are easier to identify, than the intangible customer experience ones. Being able to deliver food in this pandemic is a resource that requires a routing algorithm, dynamic pricing algorithm, third-party to engage drivers, bikes, fuel, incidentals and vendors to supply the meals.

The resources you import from the system, might be re-purposed and used in an altogether different purpose, rather than what was intended by the host system. Your intelligence applied to the transformation of such resources to augment them, is the magic resource, which makes your startup unique.

However understanding how each of these resources come together, and how you are importing them from the systems that generated these resources, will allow you to augment them better. The demand may have skyrocketed and therefore, a new algorithm to rate waiting times at vendors, would be weighted before figuring out the routing to the customer’s location. Considering the system (humanity) from where the driver hails (before being replaced by a bot) a driver who could get a meal or two between deliveries during a pandemic, might be much more likely to stay with you longer, even if he has to work harder for essentially the same amount of money.

(3) Some experts label this as “customer experience mapping” or “customer service” or UI/UX (mislabeled). However this ends up being either a quantifiable formula, reducing feedback to numbers, and calculating the NPS of the sample size to extrapolate non-personalized findings that don’t really matter as much, except for the large behemoth companies, who couldn’t care less, because they have an apparently endless stream of customers/ consumers.

A systems driven approach to etymologically identify and rank the resources imported to create your product/service, would logically translate into the most efficient system of exports, for your users.

(4) Before building your MVP or MDP, identify and sketch out a basic systems process tree, in terms of systems and resources.

Here, systems are the holders or the possessors (for want of a better word) of the temporal source of such energy. Resources are the energy (mostly labelled and structured data, insights, numbers from a csv, etc.), that you need to import into your product to make it work, whether as a critical resource, or an auxillary one. Even the js you borrow from the jquery cdn is a resource. Someone wrote the code for that, and there are still bugs, there is a cost to it, whether you recognize it or not. When you think deeply, even programming languages are resources, but ones we really can’t do without. So even the choice of a programming language is an immense decision that will impact your entire product/service.

Instinctively, our impulse drives us to import all technical resources in order to build and ship faster. However, if resources were deployed rationally (in decreasing order of user-perceived value), the number of technical imports we use have a declining marginal rate of return on utility.

The cut-off number would be for you to determine, in your field of operations.

Conversely, there is another relationship with the complexity of technical systems as we import additional resources; a direct correlation exists between the number of resources imported and the complexity (and therefore time taken) to manage the system over the long-run. The curve has a growth factor, that increases the quantum of such complexity, the more time passes from the distinct point in time, that the product was actually shipped.

(5) Map out the critical resources and have a discussion among your team, weighing the PRO’s and CON’s of each of these resources. If the resources run too long, you know you’re on the right track! Just deal with the critical ones, and make sure you document these conversations, in as much detail, as you can, so you will understand the context, should you need to audit in the future.

(6) Lastly, and most importantly for your dev team’s sanity, you can make development debt tradeoffs but do not make trade-off’s where you know of a high enough probability that the imported codebase, could be unstable/unsupported or transient, or if there is a potential licensing issue or purportedly ambiguous or ambivalent language in the license terms.

Alright, I can hear you thinking:

I got all that down, is it really going to make a difference? Can you show me a few examples of how this thing works or has worked for others?

Yeah! That’s what I’m here for. We’ll check out how cleanly the principles of this framework, applies to startups that have consistently out-performed their peers and are market-defining companies in their own right, you can extend that hypothesis and give it a whirl for your next product build.

Cautionary NOTE: No direct or causal relationship is being claimed between the application of this framework as being singularly or primarily responsible for the success of any startup. The relentless struggle for countless days and nights in the flawless and exceptional execution of any strategy is what wins the market, any given day.

I’m simply going to explain the application of this theory through examples of market-leading companies, the products of whom, we all use, love and aspire to be, in our own dominions. These startups have made millions and billions of dollars and have essentially rocket-shipped their growth curve to Elonesque velocity (basically faster than the speed of light! just kidding).

We’re not yet going to Mars but in the next part, some of these companies’ valuation sure have soared to orbit and beyond.