Or: How to architect a product development pipeline the best way possible.
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!
How do most companies architect their development pipeline (meh):
What a productive product development pipeline should look like (⚡️):
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 👩✈️ vs Implementation 👨🔧
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.
It involves:
- active communication with non-developer team members,
- validation with industry experts,
- setting a base for development motivation 💪, speed 🚄 and quality💎,
- using feedback from development to improve the base,
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.
It involves:
- individual features
- following the style-guide and architecture patterns
- being productive in an immediately visible way
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.
Be analytically business driven with product development 🔬
Build in order of what matters first
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.
Be mindful of Opportunity Cost
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:
-
Didn’t make a good enough market analysis for the current iteration of your product.And you should think about that a bit more before getting a team of very specialised people to work on something you are not sure of yet.
-
Are focusing on solving a problem with no increasing returns when there is one right next to it with them.Sure, reducing the cost of developing a product is something to think about, but if your product does not have a return orders of magnitude greater than the costs of development then reducing the cost of development won’t turn it into a scalable business.
UX/UI should be validated by all before Coding 🛸
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.
Q.A. Continuously by Everyone 📐
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.
Experienced professionals are a lot cheaper
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.
Product owners (Architects) are the product 🛠
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.
Concluding
In order to:
- build and then maintain a product
- the fastest,
- with the most quality and
- as well connected with what the market needs as possible,
It’s important to:
- Be sure of what you want,
- Know that what you want is worth the cost and then some,
- Prioritise based on what gives you the biggest return,
- Iterate over potential conceptual and UX/UI solutions before starting to develop,
- Be mindful about the differences in responsibilities, focuses, benefits and shortcomings between architecting and developing,
- Have everyone test the product being built while it’s being built, regularly,
- Have Experienced people in charge of architecture or Time to make mistakes,
- Have Manageable people responsible for the outcome
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.
Keep in touch
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).