![\"Screen](\"https:\/\/michaelwilding.com\/wp-content\/uploads\/2015\/08\/Screen-Shot-2015-08-02-at-15.43.54.png\")
<\/a><\/p>\nThat\u2019s what we do for every single product or project we have. And it\u2019s very effective. I would love to say that I came up with the process, but I didn\u2019t. Or at least I didn\u2019t come up with the initial structure but have added to it slightly.<\/p>\n
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.<\/p>\n
I\u2019m going to run through the different stages now so that you can begin to implement it in your own business.<\/p>\n
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\u2019t we want to ask why because a lot of the time we can break them down into segments that will.<\/p>\n
I like to start at the Icebox.<\/p>\n
This is where all the ideas go. If we\u2019ve got an idea then we drop it into here. It doesn\u2019t mean it will get developed but it won\u2019t be forgotten. Think of it as an idea storage box where you can put every idea (good or bad) you ever have until you\u2019ve decided whether to make it or delete it.<\/p>\n
We discuss all the ideas in the Icebox and when we decide to make one it moves into the Backlog stage as it\u2019s now officially a backlog in the development chain.<\/p>\n
The Backlog is essentially the queue for Discovery. You could drop your projects straight into discovery but we find there\u2019s 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.<\/p>\n
Discovery is the place where you discover what your product is about, usually with other team members. You won\u2019t 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.<\/p>\n
But\u2026 if you\u2019ve just got the general idea for a product and haven\u2019t nailed down the specifics this is the stage where you get those set in stone.<\/p>\n
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.<\/p>\n
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.<\/p>\n
In other words\u2026 is the amount of time it\u2019s going to take to create worthwhile what we\u2019re likely to get in a return on the product.<\/p>\n
Once a project has been put into Quote Approval you can either move it back to Quote, if you\u2019ve got questions or want something changed, drop it back into your Backlog or Icebox if you don\u2019t want to move ahead or\u2026<\/p>\n
Move it into the Wireframe stage.<\/p>\n
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.<\/p>\n
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\u2019ve 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.<\/p>\n
The Dev stage is where it all begins to happen!<\/p>\n
The coding begins to take place or the product starts to get created.<\/p>\n
Once your developer or product creator has started working on a product then they should move the product into the In Progress stage.<\/p>\n
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\u2019t need to worry about it until your staff or outsourcer moves it into the Test stage.<\/p>\n
When you see a project in the Test stage this means it\u2019s been completed and needs to be tested, if it\u2019s software, or reviewed.<\/p>\n
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.<\/p>\n
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.<\/p>\n
This is where the project will now sit until it\u2019s officially released. When it\u2019s publicly released you can move it into the Closed stage which shows that the product has now been released and is functioning.<\/p>\n
You can follow this development approach for new products, updates, bug fixes and pretty much any kind of project you can think of.<\/p>\n
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.<\/p>\n","protected":false},"excerpt":{"rendered":"I promised a little while ago that I would share the workflow that we use to develop our products rapidly. And today I\u2019m going to share it with you.\r\n\r\nIt\u2019s not complicated, but it is very effective.","protected":false},"author":1,"featured_media":782,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"image","meta":{"footnotes":""},"categories":[108,11,52],"tags":[],"location":[],"_links":{"self":[{"href":"https:\/\/michaelwilding.com\/wp-json\/wp\/v2\/posts\/778"}],"collection":[{"href":"https:\/\/michaelwilding.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/michaelwilding.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/michaelwilding.com\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/michaelwilding.com\/wp-json\/wp\/v2\/comments?post=778"}],"version-history":[{"count":0,"href":"https:\/\/michaelwilding.com\/wp-json\/wp\/v2\/posts\/778\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/michaelwilding.com\/wp-json\/wp\/v2\/media\/782"}],"wp:attachment":[{"href":"https:\/\/michaelwilding.com\/wp-json\/wp\/v2\/media?parent=778"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/michaelwilding.com\/wp-json\/wp\/v2\/categories?post=778"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/michaelwilding.com\/wp-json\/wp\/v2\/tags?post=778"},{"taxonomy":"location","embeddable":true,"href":"https:\/\/michaelwilding.com\/wp-json\/wp\/v2\/location?post=778"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}