To operate the business model you will also need to martial your resources and action processes.
Your specification needs to outline these items too. The resources and processes are the glue that keeps your business working. If the business model is the machine, your resources and processes let you turn the handle that powers the machine.
Let’s demonstrate this with an example of an e-commerce website:
- Our business model is selling product online.
- Our key resource is an e-commerce web site.
- Our processes are the systems we we use to sell, ship and nurture customers.
It is useful to breakdown the core elements of the business like this. These three elements work together. So if you have a resource it must work with processes and the business model.
When goal setting, it is important to keep this context in mind. We want to have a finely tuned machine working together harmoniously and generating profit.
I’ve seen many websites bloat their sites with vague business models, surplus technologies or business processes that are not focused on their core goal – being profitable.
When we are writing our specification we should keep this relationship in mind.
Resources (The Technology Stack)
Although your resources include all the tools of your business, for online businesses we are invariably discussing the technology.
I like to use the term ‘technology stack’.
Stack is another jargon word I’m afraid. It’s a collective noun for all the different technologies that you will use. Importantly, it describes how these technologies work together in a cohesive way. They stack on top of each other in an arranged order.
The technologies you choose will be inter-related to each other. Only certain software plays well with each other. When we consider our stack, we should be looking at these connections.
But before we start looking into the specifics, it is better to identify the role these different tools will fulfil. That way we are flexible to find an arrangement of technologies that will fulfil our needs rather than shoe-horning in tech that compromises on functionality.
Let’s look at an example. I’ll outline a typical technology stack for an e-commerce business:
- Web Hosting
- ECommerce Platform
- Standard Sales Module
- Wholesale Module
- Subscriptions Module
- Payment Gateway / Merchant Account
- Warehouse and Inventory Management
- Email Marketing
- Help Desk and Support
- Accountancy Software
Once we have identified this list we can start adding out tent-pole items. By tent-pole I mean the most significant elements in your stack, from which other technologies connect to.
For instance, if you are using a specific accountancy system and are loathe to move, then this would be a tent-pole item.
Identifying these can help with the creation of the spec. We’re identifying what elements we need, what wel would like and what is inflexible. We’re identifying your technology goals.
The Business Processes
Business process are the glue that binds your technologies together to fulfil your business models. It’s the bit between receiving an order and sending it, between a customer complaint and resolution, between a return being received and added back to your online inventory.
Some you can be flexible with and others will need to work in a specific manner.
Identifying the goal of each process provides the supplier an opportunity to think creatively around a problem. Building solutions is all about problem solving. At the blueprint stage we want to allow problem solving to fulfil the core needs, the core goals.
So far we have identified the following core needs of the business:
- The business model
- Business profitability
Let’s look at an example to see how we can best articulate the core needs of a process.
For instance in our example e-commerce company we have a returns process that currently works as follows. They manage all returns manually using a spreadsheet. Once a return is received they follow their process as follows:
- Item received
- Mark item in spreadsheet as returned
- Add stock to inventory management system
- Email customer confirming return received
- Refund item to customer on payment gateway
There are 5 steps here and much manual work. We want to fulfil our core requirement of reducing costs and being profitable. Therefore we could describe the goal in this instance to be:
Optimise this process so more automated and takes less time.
Perhaps this takes 15 minutes per refund. But if in our example the store is now receiving dozens of returns a week, then the labour cost is not inconsiderate.
Suddenly you might have 6 hours work a week just managing returns. This is certainly something that can be optimised. Adding this as a goal in your spec helps you give context to the decisions that need to be made in your technology stack.
Communicating these goals to our suppliers allows them to use their insights to re-imagine our processes, rather than prescriptively following our established setup.
A good spec does not necessarily write the in’s and out’s of what we need programatically. We’re not prescribing a specific way to achieve the goal nor are we forcing the technologies that need to be used. If there are inflexible elements then we note it, but we are trying not to assume anything or force a particular method if we don’t have to.
This allows freedom to approach the problem without any bias and find the best solution for your business.