As a startup, you may daily struggle with various conditions and advancements in your field. You may have good or horrible ideas, great visions, a strong sense of mission and commitment. And you’re working on your product. But what is your product, really? To understand that, let’s talk about business model considerations.
What does a business model mean to you?
A business model is actually what you do on a daily basis. Your product or service isn’t. If the business model doesn’t work, you don’t (or soon won’t) have a business. That’s why your business model should come before your product.
How can you manage your business model?
Your business model is like a map that shows you the way to success, or failure thereof. Your job is to refine your steps, so that the risk of failure is minimized.
A good way to do this, is to set up a validation plan for each component in the model. The Lean process would be extremely helpful for this. Your process could look something like this:
Build
- Draft out a quick Lean Canvas, based on your model.
- Discuss with your team and refine the hypotheses on every block on the canvas
- Try to define the weakest (riskiest) component. Start with that. Quite often, when starting out, the weakest component is the customer segment(s).
- Outline a validation plan, to validate or invalidate your hypothesis. A hypothesis that has not been validated or a leap of faith are only good as a starting point. But if you take them for granted, they can send you chasing your tail in all sorts of harmful directions.
- Define an experiment or more, and write up a report for each, analysing the steps, leaving the results fields blank for the moment. A validation plan can include as many experiments as needed to validate the hypothesis.
- Build whatever your experiments call for. Be sure to set them up in a way that you can get solid, consistent batches of information in return, to draw conclusions from.
Measure
- Run your experiments in a time-boxed manner, so that you can ensure that you keep learning something every week.
- Measure everything important. Be cautious. Procrastination and denial are quite easy to creep in to the process and blind you against any alarming findings. Ultimately, don’t let ego hinder your confidence.
Learn
- Analyse your findings. If you come up against any problems, you can use the 5 whys method for a root cause analysis, to find what needs to be changed. Learn from any and all mistakes.
- Use your new knowledge to refine or entirely overhaul your Lean Canvas, accordingly.
- Start over.
That’s a process that will make for a Lean Startup approach.
Agility in your workflow works wonders
Since our main purpose, at least during the first stages, is to learn instead of earn, knowledge is inherently our currency. And we should facilitate it, as required. Knowledge is your currency (or value) in the first stages. You should treat it as such. Knowing what your customers need and how you could better help them, will ultimately help you create the greatest possible value for them. In turn, they will return that value to you, providing valuable feedback and getting on board with your product or service (subscription etc). If the value you receive is greater in numbers than the one you provided, you’ve got yourself a business.
So, that’s a lot of work. How can you organise it and have it finished in a timely manner?
Be agile. Learn at each step and use the knowledge to revisit or rethink anything that does not work as expected. Even your business model. Continuously improve and refine your business model. This is of utmost importance. Otherwise you could be flying blind into a storm, without even knowing it.
If you’re using SCRUM to organise your work, you’ve probably broken up your entire development process into sprints. And there is more to them than simply being small, digestible little weekly plans of work. They can help you in goal setting – and goal reaching, for what it’s worth. How?
Set a sprint scope – it’s important
The product owner sets a sprint scope for every sprint. This is especially helpful in light of tasks (or user stories, or any type of activity) that require some work to be done by more than a single team member. Nothing like a chance to brush up on your T-skills, right?
The sprint scope helps define the minimum criteria for success, as well as refine the definition of “Done”, which is the consensus over the minimum set of results by which everyone agrees that a task is actually “Done”.
Without a sprint scope, the sprint might as well be simply a set of personal schedules/agendas for each member. This often precludes team work and know-how transfer.
Workflow optimisation
If you are in one of the first stages of development, mind you, you should only optimise your processes and workflow. But not your product or service. This is a time for validation and learning. Not for optimisations.
That means that your future sprint scopes could call for – and accept – changes that would bring you closer to achieving the objectives defined in your business model. Don’t fear change. Mindful changes that come from recently acquired knowledge about the market, competition, channels of communication or distribution, or more importantly about actual customers, will get you where you need to be a whole lot faster.
What about emergencies?
You’re building a business. Everything is an emergency if you’re not viable yet. So, what should you do with all these tickets and requests and feedback and so on? They all interfere with your sprint scope, mostly against it.
Be mindful of your stage of operations. Be mindful of your runway.
Will you be able to brook such distractions in your workflow?
If not, you could be in trouble. Use your knowledge from previous sprints to prioritise your distractions as normal tasks, and try to incorporate (or distribute) them to one or more of the next sprints, in a way that they won’t change your scope.
For example, if you’re working on a validation plan that will help you refine your customer segments and/or addressable market, you should use customer feedback and market research to guide your steps.
Does one customer ask for a feature, or do many customers ask for it? And how many is actually “many”? That goes to say, are these customers generating enough revenue for you to help you break even or, more generally, to avoid losses with a positive cash flow? In essence, is the decision you just made the most financially sensible thing to do?
Knowing when it makes sense to invest some more time and effort to a feature or customer request, is crucial to your success in these first stages. It also helps you make sensible use of your runway, avoiding unpleasant surprises, such as inadvertently running out of money. A common failure, not to be taken lightly.
A way to handle “emergencies” while reducing risk
If you’re being accelerated throughout your best stages, you should use all the help and advice you can get from your friendly neighborhood Venture Builder. That said, the best way to simply explain this is by example. So, here are a few considerations:
Is it a bug? (urgency factor)
|
||||||
|
||||||
|
||||||
|
Is it customer feedback? (problem/solution fit)
|
||
|
||
|
Whatever it is, do you have the budget (cash, HR, time) to do it now?
- Yes
Consider your stage and prioritise it accordingly. Do not spend investment money without proper consideration. Doing so, may avert a future investor from coming on board or even deprive you of a follow up investment. To be fair though, this also depends on the right timing. - No
This may actually be great for you! It will force you to defer actual non-priorities to a future sprint, when it will make more sense to take on the task. It may be a sprint where you decidedly repay a certain technical debt altogether. This way, such tasks are easier to fall within budget and within scope.
Postpone vs prioritise
Odd as it may strike you, all this consideration about postponing a task until a later time in the project, is not about procrastination or postponement. It is all about logical and sensible prioritisation.
Proper prioritisation deriving from educated decisions goes a long way toward proving your idea into a viable business model, instead of a randomly distributed effort. Besides, in the startup world, we can never get an “A for effort”. But we can sure get an “A for results”.
Cost of delay
Practically, if you find yourself on the crossroads, deciding among two or more different projects or tasks, prioritisation eventually falls into the realm of financial sensibility. Which project or task will cost you the most if you don’t do it? Besides this being a way to find out which project is the riskiest, it’s a very important consideration with respect to your available runway.
To properly prioritise these projects or tasks, find out their duration and what your income would be if they were “shipped” to customers. A rough estimate that would drive prioritisation would be to divide the income from this project in its duration by the project’s duration. Comparing the results would help you make the most financially sensible decision.
The result from this calculation is called the “Cost of delay divided by duration – or CD3”.
e.g. CD3 = [Income for this duration] / [Duration] = [$1000] / [2 weeks] = $500
How to be smart about it
Maximise the impact of your releases
Since this is all about an exchange of value between you and each customer, you should always be listening. If you know their problems like the back of your hand, the greater the value you will be able to deliver for them. The greater the value, the better your traction, retention and (healthy) habit-forming qualities.
If you manage to deliver the minimum amount of value that can get your customers “hooked” on your product or service – in a good sense, of course – you’ve probably hit “home run”.
Consider all this on each of your releases. Each release should have the potential to be shipped to customers for added value.
No need for overtime
Of course, when you’ve achieved a minimum level of sophistication that allows you to sufficiently manage your business model, a happy side-effect is that you won’t need to overwork yourself or your team. Your methods and tactics will be efficient enough to allow for much more productive work and greatly superior results. That’s a serious consideration, on the long run. Avoiding burn out, is one of the best ways to help bring your project to life. After all, Scrum-wise, keeping a sustainable pace is one of the key principles.
, avoiding overtime should not go against your sense of dedication to your business and your team.
What should you take away from all this?
Your business model is not just a model. It’s your product. If it doesn’t work, you have no business. And it’s a live organism. It changes as its environment (or factors) change. You need to tend to it, almost as if it were human. That is to say, such is the importance of it remaining an ever-improving entity.
Always be on the look-out for the weakest component in your business model. Always try to improve and refine it, so that it serves you the best in creating a healthy, scalable business.
[newsform label=”Learn more about your startup”]
