So here you are, you've just had this Eureka moment while taking a shower. The idea seems flawless - you are so certain this will work out that you have already started to think how you will spend those truckloads of money that you will make on the idea. You know little or nothing at all about software development.
Or maybe you feel fed up with the internal procedures and slow-moving processes within your current company. You have an idea for a software product that will greatly improve people's lives and bring you fame and glory in return. But you know that pursuing the idea internally will make you retire before you start seeing the results.
Finally, you've experienced many trials and errors so far, trying to push your ideas into the market.
The number of scenarios is endless, but one common denominator between all of them is the need for software development - bread and butter for a software house. And I could end up here, with a slogan:
"Once you have a backlog, come to us, we will transform it into high quality working software"
Although the above thinking is common in the industry, in this article I will try to explain why it's wrong. Very wrong.
It's all about execution
John Doerr, the author of a bestseller book "Measure What Matters - How Google, Bono, and the Gates Foundation Rock the World with OKRs” is famous not only for his work on OKRs, but also for the following phrase:
"Ideas are easy, execution is everything"
While working on software solutions, I came to the conclusion that software development is just a part of the whole execution process. One has to rise a few steps above the clouds to understand all components of software product creation. This involves, for example:
- Identification of potential users’ needs
- Designing a solution to a given problem
- Testing multiple variations of a potential solution
- Developing minimum functionality for live release
- Actual release process and continuous deployment
- Communication with users
- Feedback collection
- …. and back to point 1
Depending on the organization size and the scale of a product, there may be some additional elements in the process (e.g. legal review and approval, compliance, security, etc.).
Why am I mentioning all these? Because there are multiple ways of carrying out the whole process execution. Throughout my professional experience I have encountered various approaches and I was able to build my own view on which ones work better, and which worse. I would probably need another post to explain the examples I've seen or been part of, so I will skip this today.
The one I am particularly keen on is a small steps approach. This is not always possible, but my colleague used to say: “Take smalls steps in the unknown terrain, otherwise you risk a fall”.
When we start a new project, we try to support a client with the decision on which approach is best. The problem arises when we get engaged at an already prepared backlog stage. The vision is (hopefully) established and we put all our effort into understanding it. Yet it is often very hard to grasp the big picture standing behind the decision of what and why was included in the backlog.
The point I am trying to make is that making us engaged at the very early stages of the idea might be a very smart move. Why? There are various reasons, but not doing so may result in lost opportunities.
1. Business Value Understanding
One of the first questions you may hear from us is what business value you expect to deliver. If you've done your homework and the answer seems strong and supported by evidence - we will work to achieve it the best way possible - my team and I will suggest items in the backlog that could be simplified if we think they might be overengineered.
2. Business Value definition
If you are not sure about your homework, it would be wise to get engaged with us to help you define such business value. Why? In our toolbox, we have a vast number of techniques that help us dig out such value, and not making use of this knowledge is another lost opportunity.
3. Years of software development experience
I learn on a daily basis. The team of people I closely cooperate with try out and succeed in many initiatives. However, we also have times when we fail and we then share lessons learned from those experiences internally. Such an approach allows us to learn what works, what doesn’t and strive not to make the same mistakes twice.
4. Team dynamics
Software development is a collective effort of individuals working towards the same goal. Our values and standards allow us to achieve great efficiency by setting up team fit for purpose. Different set of skills is required for a large interconnected project compared to simple mobile iOS app. We have those roles on board ready to work from day 1.
5. User research and validation
Have you done research with potential users? Validated a potential solution? No? We can help with that too - by taking advantage of our User Experience specialists. They study user behaviour, psychology, design principles and are willing to share this knowledge in order to build the next great product.
6. Hi-fidelity mock-ups
You want a clearer view of what the piece of software will look like before its developed? This poses no problem for an in-house team of Visual Designers who can prepare high fidelity design screens.
7. Domain knowledge
Don't know the industry? It’s also fine. Personally, I’ve worked in domains such as e-commerce, taxation, finance and smart office. If your domain is different, I can always ask my colleagues, who are experienced in other domains, to join the discussion.
8. Constant feedback
At a very early stage, we are able to provide some advice to make sure if the approach you want to apply is likely to succeed. We can indicate flaws based on what we have already encountered, and if you are the type of a person willing to accept such advice and to adjust - that brings you closer to proper execution. At the very minimum, we offer to be a sparring partner to stress-test the ideas. The list could go on and on. All that is to show is that the number of options is endless. It sounds like a no-brainer to test check the above on your own.
Your idea is yours
You might be wondering: why is he so open to share his experience? And his colleagues as well? With such knowledge we could build our own products and transform Objectivity from a software house into a product company. We could steal your idea and make it ours. Yet we don't do it. Why? Many reasons.
- My colleagues and I - we don't do it for free. We are not a charity organisation and you have to pay for the knowledge you receive from us.
- We are a bunch of experts who like to work on engaging projects, making people happy and feel a sense of pride when other people’s life is made easier and more pleasant.
- There is always an accompanying Non-Disclosure Agreement
- We are already a product company. But our product is software development. This is our bread and butter and this is where we strive for perfection.
Finally, what stops us from taking your idea and making ours? Many of us know how hard it is to run a company. I've been running one for 10 years before I joined Objectivity. We are passionate about software delivery and software product development, and what we offer in exchange for onboarding us is expertise.
As a Software house, Objectivity is not a one-stop-shop which will take care of your Accounting, Human Resources, Marketing, Logistics and many other jobs needed to successfully run your business. These aspects are yours to look after, and how well you execute them will define the degree of success waiting for you. Your business success depends on it. We can, however, take care of that small (or large?) chunk of a software-related headache so that you can focus on what really matters.
Do you agree with me?
It is important to stress out that I work for Objectivity - a software house. Therefore, all views presented in this entry are based on my own perspective. If you disagree, please share a comment and I will be more than happy to get engaged in a discussion.