If you are engaging with a development partner you may be given a timeline of months, or even years, to complete your project. This is due to the linear nature of the work.
You will want to make sure that the developers have the correct requirements. This usually means that a “design phase” will need to be completed and signed off before development can begin. You may even have a “discovery phase” to help you identify the requirements. All of this makes the project longer. I am going to share some tips and tricks that we use to help our customers reduce the time it takes to get to a working product.
Warning: product development moving faster requires more effort!
If you want your product development to move faster, you will need to be available more. You should expect to be involved at least weekly, if not daily, to progress the design and development of your product. If this is too much for you, you should consider getting help, or whether a longer timeline may suit you better. Not everyone needs to rush to delivery.
I have made a big assumption here; you intend to work using some sort of Agile Software Development methodology. Be it Kanban, Scrum, Extreme Programming, or anything else. If you don’t, you should think about reading this article to help you choose.
1. Listen to your users
Before you do anything, work out who your users are and then talk to them. It’s pretty simple. The intended users of your application are the correct people to tell you what it needs to do. They are probably not going to come up with the technical solutions but they will be able to tell you what their problems are, what is difficult for them, and how their lives or jobs could be made easier.
You should find a small group of intended users at the start of your project. And then keep them engaged throughout discovery, design, development and testing. They are the best possible contributors and reviewers of your ideas and product. Invite them back to review the design, test the features and use it in earnest during your beta.
2. Only work on features you cannot live without
You are bound to have heaps of ideas for your product. Things you’d love it to have that will delight your users, or bring in more users, or allow you to expand. However, you need to push anything that isn’t absolutely vital to the bottom of the list, and work from the top.
Prioritisation should be challenging and will probably stress you out. Here are some questions I ask myself to help me prioritise work for our customers:
- What do I need to have in order to proceed with the process?
- Without this feature, will the application still work?
- What value is the user getting from this feature?
- If I don’t have this, how will it work?
Work your way from the top of the list to the bottom, and at each feature, ask yourself these questions. Then move the feature up or down depending on its relative priority against the other items.
Your development team can then start from the top, while you work on keeping the rest up to date. You do not need to know the order in which the work should be completed, only that you have chosen the most important things and moved them to the top.
This approach will mean you can design less, develop less and product development will move faster.
3. Start development as soon as possible
All your most important features are at the top of the list, and you have completed the design for those features, but not for the entire application. You should start developing. If you know those features are vital for the app to function and there’s no way they are coming out, then you can safely start developing them. You’ll be able to add more features as and when they are ready/needed.
This is the single fastest way to speed up product development. Simply allow the developers to get started.
At the start of any new development project, the team will usually spend at least one sprint completing all the technical tasks required for you to run your app. For example, creating environments, setting up source control, defining the architecture and how the app will be structured.
There are a few things that you should be aware of with this approach:
- You won’t know exactly how everything in the application will work
- The developers may need to come back to and enhance features later on
- You must have a clear vision of what you want to end up with and be able to share this with your developers, to ensure that you are all working towards the same goal
4. Evaluate what you have at the end of every sprint
Your development team will be releasing new working functionality at the end of every sprint. Let’s assume for the purposes of this article, that the sprints are two weeks long. That means that every two weeks you will have new working functionality to play with. Initially it may not be very interesting, just a login screen or homepage, but as the project moves along more and more features will be added that you can use.
You must complete testing of these features!
As soon as new features are added you should be using them; working with them; showing them to users. Then as soon as you have enough features to satisfy your users, even if it’s only a small sub-set, you should launch.
There may be more features you’d like, or that have been suggested, but if you can launch, you should. Closely evaluating the output of the sprints like this means you will undoubtedly launch earlier than initially planned, but it means so much more…
- You will have a better knowledge of how the application works
- You will identify, and therefore fix more issues
- Your users will have a chance to feedback on features at a time when they can be easily changed without wasting money
- You will be focussed on a live launch from the minute you start using your software
Run a private or public beta
Once you have reached the point when you have enough features to satisfy some of your users, you should be able to launch a beta product. Beta is simply a fancy software way of saying “early release”. It means allowing people to start using it before it’s launched to the public. You can either have a private beta, where you invite specific people to use it. Or a public beta (usually after a private is done), where anyone can start using it before it’s finished. Apple and Android often run public betas for new versions of their operating systems.
During the beta phase, you can gather more useful feedback from users. It’s up to you where you focus your development team during this time:
- Incorporating user feedback
- Fine tuning and polishing existing features for launch
- Working on the next most valuable set of new features
You are likely to get lots of excellent feedback to extend your product backlog during a beta. But it should give you a chance to prove your idea, your product and your commercials before you head into a full product launch. It also means you have a working product earlier than originally expected, which should satisfy investors!
6. Be prepared to feel uncomfortable
This point applies to all of the above. You should aim to release your product before you are ready. If you wait until it’s perfect, you have waited too long. The tech industry moves so fast, you cannot afford to wait for every feature to be perfect and to have covered the needs of every user.
Use the Pareto Principle to input 20% of the effort, to achieve 80% of the results. Don’t waste time on nice-to-haves, just focus on the core of what you need and add the rest later. Once you have users, they are going to love receiving new features every month, so don’t shy away from having those features on the back burner until you are ready to start delighting people.
The heart of getting product development to move faster is having a team you can trust working on it. You need to have a close working relationship with a group of people you can rely on to execute your vision. None of the above is possible without that.