Following on from what was covered in Part 1, now I’ll look at being ready to go to market.
First and foremost you want to ascertain whether or not a custom software development company is right for you. Custom software development addresses the problem where there is no pre-existing software that you can licence to enable you achieve what you require….or, you are looking to build something completely unique to sell in its own right. So researching readily available pre-existing options is my first recommendation. It’s typically cheaper and easier to change a business process to match an existing product than it is to create something from scratch. That being said, there are a myriad of reasons why custom software development will deliver a greater ROI for your business. For start-ups with an application idea – the process is similar. Before you invest thousands of dollars into a venture, you want to ensure you have a strong market available for success, therefore competitive analysis and determining your key differentiator is very important.
This raises a dilemma commonly faced by start-ups – that is – how to balance the need to protect your idea, versus the benefits obtained from discussing your idea. I strongly encourage start-ups to discuss their idea with as many people as possible. Communicating your idea to others solidifies your own understanding of what it is you want to achieve. Additionally, you open yourself to insight and experiences that others may have, which can contribute to improving your idea, or killing it off early before you’ve invested heavily in it. Don’t let the fear that someone will steal your idea get in the way of taking action that will cause your idea to become a reality.
Having established custom software development is right for you, the more clarity with which you can present your vision, the more information a supplier has to work with, and the more detailed a response they can provide. Before calling a supplier, you should be able to:
1. Articulate your vision in 3 sentences or less
Your vision provides the context for what you want to achieve. Discussing this with a supplier gives you both a shared idea of what it is you actually want to achieve. Your vision also becomes the yardstick for later in the process when you’re prioritising features, defining goals and establishing a minimum viable offering. When discussing any features, you should be able to answer the question ‘how does this fulfil my vision?’ If you can’t, you’ve identified cruft to be eliminated or a reason to revise your vision.
Your vision should be specific, measurable and quantifiable – avoid abstractions and hyperbole.
2. Don’t mix how with what
I love the ‘who can do what’ discussion because it keeps things at a high level and forces people to think about the actual business requirement, rather than the implementation. As an example, ‘a customer can place an order’ is far more informative than ‘the user picks products from a list then clicks a button that submits an order’. In the second example – the business requirement of having customers place orders is lost within the client’s interpretation of how the feature should be implemented. This detail is important later in the process, but for ensuring engagement readiness, having a high level list of ‘who can do what’ is enough to build a picture of the number and complexity of the features you want to implement.
3. Define the scope
Defining scope provides the boundaries within which the vision and ‘who can do what’ exist. Ideally you want to provide numbers on expected levels of use, e.g. the number of users, amount of data stored, number of web pages etc. It’s ok to estimate – but be realistic as designing for high capacity scenarios gets expensive, quickly.
If your solution is intended for use outside Australia specify if localisation and globalisation (e.g. multi language, time zone and non-Australian currency) is a requirement.
Include what platforms you are targeting. Typically this is as simple as web or mobile (iOS, Android and Windows Phone being the most common mobile platforms), but can be more detailed when integrating with third parties, extending existing applications or designing applications for the enterprise.
Being able to passionately articulate your vision, ‘who can do what’ and scope is a fantastic start to engaging with suppliers. I strongly encourage clients to discuss this with as many people as possible – discussion solidifies personal understanding and will often draw out new and exciting ideas you may not have considered previously. Passionate discussion is infectious – and if you can share that with your supplier, all the better.
If you’re not ready to engage a supplier, that’s ok – there are still things you can do. At Kiandra we often deal with visionaries who don’t know where to start, start-ups who are unsure about what’s technically possible, and businesses with a requirement that outweighs their budget. In these scenarios I advocate a project workshop.
A project workshop is a short, paid engagement that gathers the project stakeholders and a team of experts – typically a business analyst, solution architect and designer with the purpose of eliciting a vision, feature set and scope in a collaborative manner. The experts provide insight and direction as to what’s possible, the impact and trade off of various approaches, and ball park figures regarding cost and timeframes. On conclusion of the project workshop the aim is to leave you with a clear vision, some indicative figures, and a clear direction of where to go next.