Product development (and by consequence any software-centered development) is a tricky process, in which you always need to make sure that you’re not only adding complexity but you also can control it.
When it comes to complexity controlling, we should focus primarily on 3 pillars:
Thinking about such aspects might give you at least high-level perspective on the affected areas, and thus you can pay more attention to those areas to make sure the complexity is still maintained and under control.
Have these questions in mind while thinking about it from that aspect. It can give you wider perspective.
What if we figured out that this new feature isn’t a good fit for the product, maybe we acquired a new market that changed our product perspective, are we ready to rollout this feature? Are we flexible enough to plug that out without affecting the user experience?
Answering those questions might leave you with a skeptical perspective tackling the increasing complexity.
But it’s clear that even with these practices, you still to formalize this discipline and get some automation around it, because guess what? It’s not always clear when are you adding new complexity, since this is more of a subtle, evolving and sometimes invisible product development behavior.
CD was adapted by many ventures as one of the pillars for software product agility. Many people break down CD into 2 major categories:
And the outcome of those 2 practices is called Continuous Delivery. A practice that you adapt to shorten the product update cycle. But is it true that it’s only about coding practices?
To my point of view, CD is an overarching practice, that not only affects the code base, but also affects several aspects like: Architecture, Usability, and Product-market fit. I’m going to try to highlight the last aspect a little bit more.
When thinking about product-market fit as a phase many products should go through, you can notice 1 thing. It’s all about uncertainty! You’re trying to measure different view for your product, study reactions, and learn from that!
Then, if you’re validating a concept, trying to get a buy-in for a specific feature, you’re actually engaged in a software development process. Having the CD practice in your mind can help you elaborate more bit-sized tests for this new concept. Instead of start working on that big, exciting feature, think about how can we change an existing view to look like the new feature? How can we separate that new view from the old view and test that out?
So you have CD in your arsenal to validate your product hypothesis, you can easily move between concepts and worry less about complexity. That helps you on the architectural side to safely land an incremental design process, in which you manage design complexity on-the-go.
CD is a great way to slowly add complexity to your product while be safe not to create negative complexity or hidden ones.
When it comes to complexity controlling, we should focus primarily on 3 pillars:
- Scope of change
- Change cost
- Escape options
Scope of change
When we think about a new feature, or a new data stream that will be added to the product scope, we should take the time to think about the scope of change. Which parts of the product will be affected by that change? It doesn’t hurt to think a little bit on the negative side: What could be broke down by such a change? How this new complexity is going to be integrated?Thinking about such aspects might give you at least high-level perspective on the affected areas, and thus you can pay more attention to those areas to make sure the complexity is still maintained and under control.
Change Cost
Think about that like you’re going to be wrong, even if you have validated outcomes, you may have to change that in the future, to what degree you can adopt this change? Does it break other product aspects if you integrated the new feature and then changed the way it behaves? Are you creating a new dependency that will cost you more if you wanted to change?Have these questions in mind while thinking about it from that aspect. It can give you wider perspective.
Escape Options
When you add new complexity to your product, do you have the option to rollback anytime? What would that look like for your product? Will you be experiencing a down time? How much time would that take?What if we figured out that this new feature isn’t a good fit for the product, maybe we acquired a new market that changed our product perspective, are we ready to rollout this feature? Are we flexible enough to plug that out without affecting the user experience?
Answering those questions might leave you with a skeptical perspective tackling the increasing complexity.
But it’s clear that even with these practices, you still to formalize this discipline and get some automation around it, because guess what? It’s not always clear when are you adding new complexity, since this is more of a subtle, evolving and sometimes invisible product development behavior.
Continuous Delivery
As per continuousdelivery.com definition, CD is: “The ability to get changes of all types—including new features, configuration changes, bug fixes and experiments—into production, or into the hands of users, safely and quickly in a sustainable way.”CD was adapted by many ventures as one of the pillars for software product agility. Many people break down CD into 2 major categories:
- Continuous Integration
- Continuous Deployment
And the outcome of those 2 practices is called Continuous Delivery. A practice that you adapt to shorten the product update cycle. But is it true that it’s only about coding practices?
To my point of view, CD is an overarching practice, that not only affects the code base, but also affects several aspects like: Architecture, Usability, and Product-market fit. I’m going to try to highlight the last aspect a little bit more.
Enhance your product-market fit with CD
Then, if you’re validating a concept, trying to get a buy-in for a specific feature, you’re actually engaged in a software development process. Having the CD practice in your mind can help you elaborate more bit-sized tests for this new concept. Instead of start working on that big, exciting feature, think about how can we change an existing view to look like the new feature? How can we separate that new view from the old view and test that out?
So you have CD in your arsenal to validate your product hypothesis, you can easily move between concepts and worry less about complexity. That helps you on the architectural side to safely land an incremental design process, in which you manage design complexity on-the-go.
CD is a great way to slowly add complexity to your product while be safe not to create negative complexity or hidden ones.
Comments
Post a Comment