To all you entrepreneurs out there: “it’s the path that counts …”, it sounds BORING, but becomes so true a wisdom in Lean-Start-Up!

“It is the path that counts, not the destination alone”. We have heard it all before, more than once. And even better, I am 100% confident that all entrepreneurs have mentioned it themselves to anyone who wanted to listen (and many who did not even) at the moment they quit their jobs and started their dreams.

But let us be honest immediately, all of those entrepreneurs are all the same and do not actively enjoy the path at all. They love the outcome, the end result, that is what they live for. They dread the hunt because that keeps them up at nights, but they love the kill so much that they keep bothering themselves with hunting, keeping a balance of love-and-hate in a daily routine. Off course that thrill of up and down, that complete rollercoaster, is what they need, by personality so to say. But the danger is aiming for goals too far in the future, being only content at achieved targets which have become too big. The thrill becomes higher, but the fall also deeper.

So far no news, these theories about the average breed of entrepreneurs have been written down by various authors already. And yes, I found them often very recognizable…

“Then where is the new insight here in this post?” one could ask while reading this. Well, I wanted to share my new-found wisdom on the old-school sayings about “the travel being the thing that counts”. This new-found wisdom lies for a large part in adopting “the lean start-up” as our companies method for new product development.

What makes the lean start-up method?

Product development according to lean start-up follow one of the main theories behind lean process management: everything that you deem logical in a process but what a (potential) client is not willing to pay surplus money for can be considered waste.

Translated into product development, lean theory is about functionalities in your product or components in your offered service. Developing in lean start-up is about making sure you add as little waste as possible in your product, thus building what the market asks for or quit trying in an early stage. The steps to lean-start-up are basically as follows:

1.       Invent the product in your head, the same way you always did it. Dream about the added value you want to deliver and find that niche gap you always knew was there.

2.       Make your idea as little as possible. Take away all parts of your idea that do not necessarily add to the core value you want to deliver, the core issue you want to resolve.

3.       Create a first prototype based on your stripped idea, the minimum viable product. This first prototype can be a 3d-printed model, a faked demo-software product or even just a set of slides explaining your basic idea.

4.       Start testing the value of your idea in the marketplace and start gathering feedback on the use, desires and feelings. But most importantly: start gathering a validated thought on what needs to be added before one starts to be paying money for its use!

5.       Keep on developing the product based on actual validated wishes from the marketplace.

Better fitting products with a higher value drive are developed this way while asking lesser funds and lower risk.

Then why this post about a link with “the path..”?

I can hear you think: “So far this post is still mostly about knowledge from other authors, where is your main climax?”

Well, here it is: using the lean start-up as a method for product development changes your periodically routine from long frustrated stints of investment and development leading to one big high or one big fail, to a process of short stints of investment and development to continuous moments of “YES” or “should be a little better”. You learn more about what you are doing and about the marketplace behind it, you work more relaxed with your developing crew, you focus only on the smallest details necessary because all other load has been eliminated, you… simply enjoy the path better.

Curious to your thoughts!

Doede van Haperen
www.lakran.com
www.again.nl
www.ehiring.nl

What makes simple in IT? Marketing versus real technology.

What makes simple in IT? Marketing versus real technology.

At the ending of 2014, I wrote a blog about the buzzword of that year being ‘disruptive’. Of course I am tempted now to wait until the end of December with publishing this blog, but why wait. It is already very clear to me what the buzzword for this year is in ‘my’ world of IT and cloud applications: ‘simple’.

Wherever you click, swipe or scroll, the word ‘simple’ seems to be added to everything the software market is producing at the moment (and yes, my software firm does the same, guilty as charged!). To my opinion though, there is usually one important part missing in the marketing. No one seems to really define what ‘simple’ is…

Honestly, so far I have seen only one firm doing a nice attempt at framing the buzz a little more than just buzzing along, being SAP in their statement of investing heavily in “consumer simple, while maintaining their business strong”. This statement kind of relates to impulses in my head that visualise a targeted definition of simple, being the way we do things at home on our sofa holding only a tablet pc. 

Beyond that I only find examples that:

1. say nothing at all, like “simple is aiming for user-centric”, which is to me nothing more than just replacing one buzzword with another;

2. are smart but hollow, like “we do things simpler”, sounds valid because it can always be more simple than today but actually is just consulting marketing, not a real brand promise; or even

3. are full-fledged lame, like naming a firm ‘simple blahblah’ and not even bother with an explanation or frame at all…

But then what? Because I am a little torn. Being a software entrepreneur (see my firm AGAIN by LAKRAN), I can highly appreciate the marketing value of a ‘simple’ promise, but as a services entrepreneur (see my firm LAKRAN ProcurementProfessionals) I greatly value the marketing effect of keeping your promises. Communicating a promise without a proper explanation is too easy to keep, or not possible to keep at all, so as an entrepreneur I think much value is wasted in the greater software market because of the lack of a clear vision on what is simple.

Considering all this, I just thought to start an attempt at focussing on some sort of definition to ‘simple’ in business software. Please feel free to react to this, might make a nice discussion.

A definition of the word simple can be found in a dictionary like ‘easy to understand or do’. But that automatically brings me to the core: what does one find easy. In checking synonyms I come a little further. Words are mentioned like ‘intelligible’, ‘understandable’, ‘unmistakable’, ‘lucid’. Checking definitions on those synonyms gives me a useful trail: “capable of being understood”.

When I take that last meaning and reflect that as a meaning in IT, I come to the understanding that ‘simplifying’ is “optimizing a software’s capabilities of being understood”. The question that remains left then is what makes a software better understood? A question that I honestly do not expect to be answering in the next few lines of text, because that is where technology finally gets the upper hand of marketing. What is actually possible? How is a software developer able to grasp that technology and make it work? How does a user relate to software? Who or what makes a user? How does a user think? Or is there more to understanding software than aiming at the users that handle it?

For now I would like to keep an open mind, and thus aim for more than just users. To me (being active in interorganisational software such as Suppliers and Buyers collaborating on one platform), understanding software should also be a ground rule for organisations, but also for the software that integrates to it, for the stakeholders that need to decide on it, for ...

And how do you make sure that a complex construct of stakeholders and technology is able to understand one piece of software? Simple (and yes, humor attempted in using this word;-)), by making sure the gap between “what they do and understand now” and “what they are supposed to do and understand with the new software” is as small as possible!

So to support a wide angle to ‘simple’ in business software, from here on I think that a proper definition (or so you want ‘goal’ to simple)  should be to “maximize output, while asking as minimal compromise/change as possible from all involved”.

Curious to your thoughts...

Doede van Haperen

www.again.nl

www.lakran.com

www.ehiring.nl