This post is about startup ideas and why sharing yours is a good idea!
I am active in the young startup community here in Denmark and one of the things I have been seeing lately is people searching for brilliant tech people, but they will not tell anything about their idea for their new startup.
I think this is downright wrong and here is why.
I am not suggesting that you share your entire business model, but share enough to get your crowd listening.
Your Startup – Your team
When you run a startup you want the best people possible to join your team, because this will give you the biggest chance of success.
However, the best people don’t come easy, they can be hard to find, and they need to be conceived that your startup will succeed or at least have a very high chance of success and reward.
No one wants to join business which is dead from the get go.
Your idea is what started it all, and what made you believe in a startup, so tell it to the crowd, and tell it loud.
Don’t just tell it to a few people at a time, tell it in the forums where the brilliant tech engineers are.
Most people have a sence that they have lost their idea and someone will steal it when they tell it.
However, as I see it, they just got a ton of feedback saving them valuable time to market.
Furthermore, it can help you hook partners and investors because you make them believe in your idea as well.
When working in a startup you have scares resources and little time, don’t waste it telling your idea to one person at a time.
Execution and timing is everything
If we listen to Bill Gross execution and timing are the two most deciding factors when it comes to success for a startup.
The idea only gets an 3th place.
And when you are the founder of a startup your most definitely want your startup to have the best probability for success.
Furthermore, we are in a time where the product starts to beat marketing.
It is more important to create a product which your customers want than telling them that it is what they want.
In these times it is fairly easy switching companies for the best product in the market.
Lastly you will have the early access effect.
This is something very popular in the game scene right now where you give out early access to a few people such that they will tell all their friends that your game is awesome!
You have the possibility of getting followers which will tell their friends that your product is awesome and they should join as well.
Having such followers or fans is crucial for making it in today’s markets from my perspective.
The conclusion is spread your idea, be ready for it to morph into something even better, be challenged by people and make your product better!
Share your idea with the world and share it loud!
In Essence, an innovative methodology, the metaphor used to describe an idea is called a Vision.
Visions are used to keep an eye on the overall goal and are a way for the team to describe and communicating about an idea.
They can be used to discover and communicate about limitations and challenges of an idea or possible solution.
A representation of a vision can take different forms, which can be seen seen as two axes, concrete versus abstract, and simple versus complex.
This means that it is possible to have four distinctive representations:
Essence vision types and representations
- Concrete means that the vision is material.
- Abstract means that the vision is immaterial.
- Simple means that the vision is uncomplicated in form.
- Complex means that the vision consists of interrelated parts or aspects.
In Essence each of these representations have a name:
- Icons (concrete simple)
- Prototype (concrete complex)
- Metaphors (abstract simple)
- Proposition (abstract complex)
The software industry uses these representations extensively today.
E.g. prototypes are produced each day and they are used to communication about properties of a product.
Icons are used for communicating about one specific property e.g. it needs to be more simple in use, like an apple remote.
As software professionals we often use metaphors for communicating about code, and likewise can they be used to communicate about a vision for the product being produced.
Propositions is a more complex “metaphor” often being a hole sentence describing the solution to a problem.
An elevator pitch can be seen as a proposition.
I have used them all with success both to investigate but also to communicate about an idea with stakeholders and other team members.
Prototypes is the representation I use the most.
Prototypes works well for testing practical aspects, however they are very concrete and can be complex to comprehend. The problem with them being concrete is that they can limit creativity and users can come to think that this is the final product.
This is not always ideal as the customer participation is needed in discussing the product on a level where everything is possible and where the team is looking for opportunities.
However, in the Pay-E-Safe’s Zebra project we used prototypes for presenting our vision and using this presentation it was possible for us to investigate the use context for the solution.
The main customer based was located in Uganda, Africa where there were a need for a payment solution as Zebra.
By choosing a representation which could be interacted with we learned a lot about how the customers in the domain would use the solution and what was important to them.
For instance we initially figured that a pin code would be to tiresome and slow the purchasing process.
However, they thought that pin codes were important because they felt that this protected them against theft.
This goes to show that representations of visions, and the choosing of which to use, is important for the investigations, the innovation of the solution, and for bringing value to the customer.
Put in other words visions can be used to understand the domain, but also for keeping a long term strategy for the product.
Metaphors are a part of our everyday lives as software professionals. We use them to describe concepts, features and even complete systems to each other on a daily basis, but what are they exactly?
Kim Halskov Madsen wrote an article in 1994 called “A Guide to Metaphorical Design” and I think this is worth a read for everyone interested in improving their ability to describe concepts that may be hard to grasp e.g features to customers, a complete system to your boss, or just a newly build class to a fellow colleague.
One of my personal favorite metaphors is The Chicken and the Pig and how these two animals can describe commitment in a project.
How to use metaphors
The article explains how metaphors should be generated, evaluated, and developed.
A metaphor should, if possible, build on already existing metaphors e.g. something already existing in the problem domain.
If a predecessor artifact is already described this can be used as a metaphor e.g. files in file cabinets can be used to describe file systems on computers.
Rich structures are important for metaphors because general or abstract metaphors can become a problem e.g. a link can mean a lot of things, a path from somewhere to another, something describing a relationship between a source and a destination etc.
One should always evaluate the applicability of the structure chosen for a metaphor: does it really cover all the important aspects? Or can it be seen as misleading?
This also relates to the fact that one should use a metaphor that is suitable to the audience. I reckon that this is the reason why business and software people often talk past each other. They do not communicate in a language which they both understand.
E.g. a pointer metaphor is fully understood amongst software developers, but business personnel can have a hard time figuring out what a pointer is and what it represents.
Metaphors should be chosen with well-understood literal meanings, as the key aspect of metaphors is explaining something in terms of something else.
Metaphors are used for seeing something in a different light; from another perspective. Therefore, metaphors should be chosen with a conceptual distance between the source and the metaphorical meaning. E.g. a credit card can be metaphorically expressed as an electronic wallet or pocket.
It is important to have one or more bridging concepts contained inside the metaphor e.g. how the pig and the chicken commit to making brunch! In this example project, commitment and cooking form the bridge.
Elaborate assumptions – it is important to explicitly express what the metaphor hides and what it highlights.
Metaphors often use triggering concepts, e.g. “to meet the customer in a new way”, and these are necessary to elaborate upon.
Identifying the unused parts of a metaphor, e.g. aspects, features, and properties, in the source domain, can be used for gaining a more profound understand of the target domain.
Talking about the target domain as if it was the source domain, can be used for understanding how the target and source domain is intertwined.
Metaphors are helped by psychical structures in everyday experiences and can be used for describing abstract concepts in terms of concrete and familiar objects.
Metaphors can even be used for providing detailed, specific design options, and as a basis for justifying design decisions.
They can help people see something as something else and describe a model of the system which they can familiarize with.
Metaphors can shift the focus of attention and create a problem setting – they can provide a novel view of reality.
I hope this can help you understand how to use metaphors as the great tools they are – both for communicating with others, but perhaps even more with understanding problems at hand in a new light.
Currently I am writing my master thesis as a Software engineer. The subject I am working on is Software Innovation and Business Modeling.
We choose to call the project Software as a Business.
In this thesis Essence, by Ivan Aaen, a software innovation methodology is used as well as Business Model Generation coined by Alexander Ostewalder & Yves Pigneur.
The project looks into the intertwinements of these two methodologies and also with the look at works from Saras Sarasvathy in form of her work in Effectuaion and Causation, and the Blue Ocean Strategy.
The usage of the Business Model Canvas combination with Essence is really inspiring and makes it more clear what innovation is and is all about – creating new products which can produce revenues.
I think that the last is often forgot by innovative developers.
Mostly articals talks about inventions but there are more things to innovation that just an invention; it also needs exploitation and diffusion.
This definition is subject to discussion and I recon that it will soon see a change, my guess is that an innovation can be said to be; invention and diffusion.
Nevertheless diffusion is an important part and can, from my perspective, be helped by using the Business Model Canvas.
Software as a Business tries looking at the diffusion part from an entrepreneur perspective, in our case with software educations, by doing a case study in a new started business in need of an innovative electronic payment solution.
This case study have showed me and my partner that innovative software is no trip to candyland and is a lot of hard work. Within the iterations for finding a design for the technical solution the business model also needs to be assessed to secure that a profitable business can be created from the technical solution.
I think that this approach is valuable for other developers making innovative software which needs to generate funds but also for software entrepenuers wanting their solution see the sunlight.
Also for developers to have some knowledge about business models will help the communication with “business people” as they often are called in developer terms.
This project is still ongoing and as of now the team are working on implementing the business and technical design which was the fruit from the first half of the thesis.