Knowing how to architect a product development pipeline is not obvious. It requires years of experience until you start to just map out the main bottlenecks, and more years to try out new methods for reducing said bottlenecks.
This knowledge is not easy to develop online and most industry experts don’t grasp it, as developers don’t prioritize it and project managers have a hard time understanding developers.
Not to say that architecting a product development pipeline is hard, on the contrary, as long as you know what problems it should solve first, where it can go wrong and measure output it can easily be done and improved upon.
Why should you listen to me?
In my busy career, I have gathered ~8 years of development / project-management experience, launched 4 startups, collaborated with 4 other startups and 3 software houses.
I am also an obsessive debater, all topics I discuss here (or anything I write about) have been thoroughly discussed with many professionals.
Ok, let’s get into it then!
This article focuses on the concepts that lead me to prefer the above recommended pipeline (⚡️).
I would be happy to write another article focusing on the intricacies of my preferred pipeline. But what I think is most useful are the principles that make me prefer it.
Architecture decisions and Implementing individual features are entirely different mental challenges. And since they are strongly connected and hard to work on simultaneously it’s important to have a strategy on how to get the most out of both.
Architecture focuses on making it easy for development and maintenance to be done smoothly, over long time periods, different developers, product iterations, and software updates.
The concept of the base was abundantly mentioned in my previous article: The Cost Of bad Code And Preventing It.
Implementation focuses on getting new features out or fixing or improving old ones.
The big advantage of understanding the two comes from understanding how to take advantage of them:
Architecture increases every developer’s speed and quality and only has to be managed by one, allowing you to empower newer developers and have single people responsible for the quality and speed of all contributors.
Implementation can be split into micro tasks and can be delegated to developers unfamiliar with more than directly effects what they have to do.
20% of a product’s potential features satisfy 80% of the client’s needs, using the Pareto Principle.
So start by delivering that as fast as possible and then keep using that principle on following product ideas.
This should be obvious for anyone working in tech, but it’s quite commonly not acted upon.
You should want your product / feature to go live fast ⚡️.
Not because this saves you development costs, instead because of the value you are not getting from the market yet.
If you don’t think like this yet you either:
In order to reach a final UX/UI Iteration for the end product a lot must happen.
Disagreements must be had, lessons learned, mistakes made, some people might even quit because they can’t accept their ideas be rejected, people can die 😵. Ok, won’t be as grim, but it should be the darkest part of the pipeline, as well as the most enlightening 💡!
If this phase is not carried out thoroughly, conceptual problems will emerge only further down the pipeline, at which point they are much more costly to be iterated over.
It’s a creative process, and like all creative processes it’s very hard to estimate on and shouldn’t be rushed. Can be sped up though, by understanding what is truly needed and focusing just on that, but in the end, it can’t be rushed. Not even by micro-dosing or anything overhyped. Just have you and your team sleep well, exercise and try to think about other topics for some hours of the day.
It’s the most effective and least costly phase to iterate based on feedback and to seek said feedback.
Once the concept and features to be first developed have been decided upon and the developers have started working it’s still not time to take the product for granted.
People that work on developing the product every day start creating biases towards how it should work due to knowing too well how it works in full detail. It’s pretty much an unstoppable thing that is even exacerbated by team size. So it’s a good idea to plan for it.
Of course, there are professionals for this and they are pretty essential. But the people involved with selling the product should also thoroughly test it regularly, as they are usually the ones with the best feedback.
In terms of the cost 💵 per quality 💎 & speed 🚄 ratio.
Getting experienced professionals to contribute can guarantee industry best quality and efficacy.
They might cost 10x more than a university graduate, but there’s a reason for that.
Programming and Design expertise comes via learning. Learning from messing up a lot, which then leads to many iterations on approaches to increase quality and speed.
The more one has learned the more he will learn for the same amount of time. Which makes learning exponentially rewarding.
However, as discussed above in Architecture vs Implementation, not all developers must start out as experienced. And working with architectures put in place is a much more interesting and effective way to learn then to simply stumble upon ineffective ways of doing things.
If you have a strong core team, incentivized to stay or at least not leave catastrophically, that knows how to delegate work and transfer knowledge you have a great foundation for scalability and longevity product wise.
In order to:
It’s important to:
Studying development pipelines evidences how different ways of handling the same problem can have drastically different results and how interconnected every decision is. As well as how improvements in the methods used can generate exponentially better performances.
Optimising pipelines is a lot like fine tuning an engine, small screw adjustments here and there and the engine’s performance greatly changes while letting you know by how it sounds.
Still hungry for project management thoughts? I wrote a previous article full of easily actionable advices: Code Project Management Quick but Huge Wins.
I write in the interest of meeting people with whom to have interesting conversations. So I would like nothing more than getting a message from you in the comments or on twitter (@esperancaJS).
Create your free account to unlock your custom reading experience.