I promised a little while ago that I would share the workflow that we use to develop our products rapidly. And today I’m going to share it with you.
It’s not complicated, but it is very effective.
That’s what we do for every single product or project we have. And it’s very effective. I would love to say that I came up with the process, but I didn’t. Or at least I didn’t come up with the initial structure but have added to it slightly.
Like everyone we have to use experts in different fields to help us optimise our business. It just so happens that one of my school friends, Alex, is an excellent software development project manager and he helped us to build this process out.
I’m going to run through the different stages now so that you can begin to implement it in your own business.
You can change it and adjust it as you like, but I have found that 95% of all projects fit easily within it and if they don’t we want to ask why because a lot of the time we can break them down into segments that will.
I like to start at the Icebox.
This is where all the ideas go. If we’ve got an idea then we drop it into here. It doesn’t mean it will get developed but it won’t be forgotten. Think of it as an idea storage box where you can put every idea (good or bad) you ever have until you’ve decided whether to make it or delete it.
We discuss all the ideas in the Icebox and when we decide to make one it moves into the Backlog stage as it’s now officially a backlog in the development chain.
The Backlog is essentially the queue for Discovery. You could drop your projects straight into discovery but we find there’s already a queue there and sometimes things can stay in Backlog for quite a while if we find better or more important projects to overtake it.
Discovery is the place where you discover what your product is about, usually with other team members. You won’t always need to use this category. If you already know exactly what your product is or does then the project can move through here to the Quote phase.
But… if you’ve just got the general idea for a product and haven’t nailed down the specifics this is the stage where you get those set in stone.
Once the idea has been set in stone it goes into the Quote stage. This is where your developers or product creators can provide you a quote on the project. They can ask you questions before quoting to clarify anything and when they have quoted it is pushed into Quote Approval for you to approve the quote.
Of course if you have full-time developers or product creators working on your projects then you could remove this stage. However I like to keep it anyway and ask for timescale quotes. This allows me to determine if the timescale makes sense to move forwards with the project.
In other words… is the amount of time it’s going to take to create worthwhile what we’re likely to get in a return on the product.
Once a project has been put into Quote Approval you can either move it back to Quote, if you’ve got questions or want something changed, drop it back into your Backlog or Icebox if you don’t want to move ahead or…
Move it into the Wireframe stage.
This stage is only relevant if you’re making software products. If not you can skip this and put it straight into the Dev stage.
If you are making software then the Wireframe stage is where your designers go and create wireframes for what your product is going to look like. When they’ve finished they attach them to the project and move it into the Wireframe Review stage where you can either reject them and make comments for adjustments before dropping them back into the Wireframe stage, or approve them and move them into the Dev stage.
The Dev stage is where it all begins to happen!
The coding begins to take place or the product starts to get created.
Once your developer or product creator has started working on a product then they should move the product into the In Progress stage.
That allows you to be able to see what each person is working on at any one time. When a product is in this stage you don’t need to worry about it until your staff or outsourcer moves it into the Test stage.
When you see a project in the Test stage this means it’s been completed and needs to be tested, if it’s software, or reviewed.
Whoever is going to be testing your products can grab one out of the Test stage and drop it into the Test In Review, again this allows you to see who is working on what very quickly and easily.
When the testing has finished either the product gets moved back to the Dev along with comments about any bugs found, or if everything is working as it should it goes into the Resolved stage.
This is where the project will now sit until it’s officially released. When it’s publicly released you can move it into the Closed stage which shows that the product has now been released and is functioning.
You can follow this development approach for new products, updates, bug fixes and pretty much any kind of project you can think of.
Combine it with the process of using an MVP to create your products and you will find that you are producing products much faster and of a much higher quality.