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).