Parallelizing the Product Process?
A few days ago I was told things needed to be parallelized, not serialized with regards to the process. To me there could not be much more of a detrimental approach.
To give some background there is currently some selling going on, as the case often is with selling you sell the next version of what you’ll have. Or really sell what you think customers want, and that gives you validation if you should build it or not. I’m generally quite happy with this process, assuming you’ll have some time to test the market out, then build it. In fact this is the way a lot of businesses proceed and is a valid process. My problem isn’t with this process, it’s that I was told that we have to deviate from this process due to time constraints.
What that means is that we’re going to build a lot of things, try to sell those things at the same time, without validation that anyone else wants this. This is very akin to the idea that 1 woman can make a baby in 9 months, but quite clearly a baby cannot be made in 1 month by throwing 9 women at it. Whether you define what should be built based on proper market research, or on some form of testing it out. Much less it should be based on requirements driven by users, not by exploring your thoughts as an outsider with no domain expertise.
The key about any process is that the outcome of one step becomes the input of another. Because of this the process simply takes the time that the process takes. While it is possible to speed the process up by accelerating phases, you can only accelerate a phase, and not parallelize the phases. This process of getting validation, defining the requirements, then building is pretty commonly the process, building seldom occurs based on a hunch and without some domain knowledge supporting it. As soon as development does occur blindly or without a clear end goal, it dies or remains stagant and un-used.