The Business Canvas Model

Writing Business Plans can be laborious and often feel like you are hiding out somewhere instead of actually doing “the work”.

I don’t know how much of it is really avoiding “the work” but I do know they can at times feel incredibly detailed, ornate and when going through the numbers at some point they become magical – especially if you are seeking to a establish a new market or concept.

After reading the book on the Business Model Canvas – I wanted to try out creating my own model for BetaRover Inc and compare the process to what I had currently done before.

What I found from doing this exercise were a few things;

  • I enjoyed doing the multiple iterations and refinements of each section.
  • I found myself adding my own pieces to the mix where I used a highlighter to indicate areas that affected each other and had a dependency on each that needed to be clarified in the next iteration.
  • Different from business plans – the relations between all the different blocks were much clearer to me then if I had done a traditional plan (having had done a number of these plans before myself).

In either case, if you are thinking to start a new company, I would highly recommend making use of the tool before getting started – it’s incredibly helpful and useful.

Whereas you might sweat spending weeks and months doing a plan to “figure it all out”, you can do this in a day and come out with an idea of where you want to go, what you are doing and what’s needed next for you to get started.

All the while asking you the questions that really matter at this stage in your organization’s development.

Measure Your Mark

Every year I like to take stock of where I’ve come from and where I’m going. It’s my own moment of looking back and focussing on what is next.

What did I do in 2017 compared to last year?

Now to break it.

Sniffing Markers: Ep 13 Problem vs Function

I’ve been really bad at not promoting the Sniffing Marker podcast enough but have to say there is some really great content here.

This episode is a great one and very apropos for those of us juggling contracting and freelancing duties and knowing the difference between the two.

In today’s episode, Greg and Colin discuss what it’s like when we freelancers/consultants are brought in to solve a problem, compared to fulfilling a specific function. We talk about the difference between those two assignments, identifying and remaining aligned to them, and how to keep working in the right direction. We discuss the “5 Why’s”, challenging assumptions and timelines, and generally ensuring you are delivering the value you’ve been hired to provide.

If you like show don’t forget to rate us, review us and share with us on our Facebook page:

What are you hacking today?

It doesn’t have to be code.

It can be how you order your food – moving from swiping to tapping your card to using your phone.

It can be how you catch those pesky rodents in your garage – moving away from the store bought traps to building your own.

It can be a new utility that saves you time in deploying your code – simplifying your workload.

It can be how you interact with people – starting with questions you know they can’t answer negatively, but only smile at and say thanks.

It can be a practice where you want to get better at a skill – so before doing anything else, you do that skill until you’re asked to join in on the other drill.

It can be how you start your team meeting – instead of asking everyone what they have done, bring a dashboard that shows them what they have done and saved 15 minutes.

Hacks – a process by which we find a better way to do something, until it becomes a standard, waiting to be hacked again.

It’s not all code and today is the perfect day to start.

Rushing to Wrong

We are all very good at Rushing to the Wrong answer when trying to solve a problem.

We throw details out the window and became blinded by the end goal and direction we want to go in.

We are so close that we can “taste it” and know we are on the right path.

But in our efforts to get there, and only when we get there, do we finally realize that we were chasing the wrong problem, going down the wrong path and had absolutely no idea what problem we were trying to solve.

When you start with everyone understanding the problem that needs to be solved, agreeing as to what the problem is that needs to be solved you change the paradigm of the project exponentially as everyone now realizes that they are no longer rushing to get to somewhere but instead are on a road to get there.