One of the things that I have learned leading development teams is no matter how small the feature, people want to build it perfectly -- at least at the outset, before deadlines loom and resources are spread across the vast plains. So what's the problem with that? Everyone wanting to build outstanding features for customers is a good thing right? I'm going to take a contrarian approach here and say: No it isn't ... at least not at first. The problem with this approach is the product teams and the engineering teams have a notion of what is needed, but not an understanding. The reason is fundamental: customers define what they actually need, while development teams define what they think customers need.
So what do I actually mean by that? How many of you have had product managers walk in a room with a first-class BRD and lay out exactly what is needed for your customers? This BRD looks like a work of art, clearly thought through with weeks of effort spent dotting 'i's and crossing 't's. Almost all of us have experienced this. Going a step further: How many of these BRDs have been delivered to spec, worked exactly as perceived, and customers giving universally positive feedback? Zero right. Let's lower the stakes a little and ask a different question: How many times has your org built big-bang features that either didn't resonate with customers or were scrapped at a later date? This happens more than we would like to admit. I call this assumption driven development. And you know what an assumption is: it makes an ass out of u and umption (see how clever I was there, I slightly modified the age-old quip where I'm not the ass in this variation -- but by doing that I am a bit of an ass -- I believe the kids call that meta nowadays before the Zuck shamelessly stole that term :-) .
Don't get me wrong, this isn't taking a shot at product managers, I have seen many engineering managers run the same playbook. What I am saying is: this approach has poor odds, and in my experience results in one of the following outcomes: 1/ Project completed but the feature isn't used. 2/ The feature is used briefly, then abandoned 3/ Customers complain because the feature isn't what they want. In other words: Good intentions <cue shudder>
My reasoning is simple, different customers will need different things and even prefer different ways to accomplish the same things. Additionally, no matter how much market research is done, there is an inherent communications gap at the outset of a project. Even if a message is clearly articulated by the sender, it isn't heard by the receiver in the same form, similar to the kid's game Telephone.
All is not lost my friends, I am not suggesting we give up on gathering requirements or even trying to understand what customers want, but instead saying that we go about it differently. Like the old saying: "How do you eat an elephant? ... One bite at a time". I have a mantra with my team that I am sure they are very tired of hearing , but is a core part of my ethos: First Make it possible....then make it easy. In other words, your first order of business should be to unblock your customers from achieving their desired outcome, even if it is hard for the customer.
What about make it easy?....slow down there champ, let's cover the first part a little more before we saunter down that aisle together.
Making it possible enables a customer to accomplish the needed with the minimal amount applied from your development team. This sounds just cheap and easy, but don't confuse this with putting out a junk product, or even selling your customers short. This is actually the best way to achieve what is best for both your customers and your development team. Why? This actually follows the first principles of lean startups and applies it to the broader brush of enterprise development. Rephrased: put out very small features, get immediate customer feedback, iterate. This results in the holy grail of enterprise development: moving fast.
I know this is a bit too esoteric for many of you, so let me walk you through an example my team deployed recently. One of my development teams is responsible for Data Lake ingestion and run a collection of ETL flows that allow extracting and transforming customer data into an opinionated data model. One of these connectors hooks into SAP and auto-magically connects about 80% of the base tables needed to run our app, with 20% requiring some form of work needed by a customer. This is due to SAP allowing customers to create Z-tables (aka custom tables) to help run their business and us needing input due to the mult-tenant nature of our app. Our product has a beautiful UX that makes the extractor setup process easy for the respective 'known/standard' SAP tables. Our first release did not have a capability for customers to add in connectors for the custom tables leaving a functional gap. Naturally, product and the engineering team wanted to build a first class experience to add in these custom tables and debate the many nuances of the experience with the next obvious step of writing a BRD. Instead we followed the Make it Possible approach by simply exposing the entire connector configuration as a good 'ole JSON file in the UI. Is it pretty? Nope -- does it get the job done? definitely. In fact, the pretty UX approach would have enabled custom tables, but would have actually limited additional capabilities that were easily enabled with the simple JSON approach. Features like altering the timing of extractions, row-level filtering, etc. These are all available out of the box with JSON, but would require significant effort to expose this granular functionality via UI components. Creating an ugly box on the UX with a JSON configuration allowed our customers to unblock themselves and extract all needed data to power their applications in a couple weeks of dev turn-around versus several months.
Have customer requested an easier UX? Yes.... and I consider that high-praise. This is exactly the problem you want to have! Consider the outcome: You have validated customers are actively using the feature you have built. They are actually using it enough to ask for more. Now we can walk down the path of 'making it easy' Great! Dig in, work with the customers and define the next small addition you will add to make it easier, rinse and repeat. For my Lean Startup readers, you will see how close this is to the exercise of achieving product-market fit. It is very similar, but even if you have hit a good product-market fit, this approach can be used for feature-use-case fit.
It can go the other way, we could have heard crickets: if so, you would have known there is not a lot of interest in that feature of the product and you have invested little. You know better than to chase bad money and as the Beatles say 'Let it Be'. You have learned more about what your customers actually value with little investment -- use your development resources on product your customers care about. If instead you go with the big-bang approach and you get to this spot (very common): you have invested a lot in a feature your customers aren't interested in -- and worse, those resources could have instead built products your customers value.
They say the road to hell is paved with Good Intentions. Consider the fallacy of assumption driven development laid out above. Resist the temptation my friends, come with me and trod down the enlightened path of Making it possible, then making it easy.
So what do I actually mean by that? How many of you have had product managers walk in a room with a first-class BRD and lay out exactly what is needed for your customers? This BRD looks like a work of art, clearly thought through with weeks of effort spent dotting 'i's and crossing 't's. Almost all of us have experienced this. Going a step further: How many of these BRDs have been delivered to spec, worked exactly as perceived, and customers giving universally positive feedback? Zero right. Let's lower the stakes a little and ask a different question: How many times has your org built big-bang features that either didn't resonate with customers or were scrapped at a later date? This happens more than we would like to admit. I call this assumption driven development. And you know what an assumption is: it makes an ass out of u and umption (see how clever I was there, I slightly modified the age-old quip where I'm not the ass in this variation -- but by doing that I am a bit of an ass -- I believe the kids call that meta nowadays before the Zuck shamelessly stole that term :-) .
Don't get me wrong, this isn't taking a shot at product managers, I have seen many engineering managers run the same playbook. What I am saying is: this approach has poor odds, and in my experience results in one of the following outcomes: 1/ Project completed but the feature isn't used. 2/ The feature is used briefly, then abandoned 3/ Customers complain because the feature isn't what they want. In other words: Good intentions <cue shudder>
My reasoning is simple, different customers will need different things and even prefer different ways to accomplish the same things. Additionally, no matter how much market research is done, there is an inherent communications gap at the outset of a project. Even if a message is clearly articulated by the sender, it isn't heard by the receiver in the same form, similar to the kid's game Telephone.
All is not lost my friends, I am not suggesting we give up on gathering requirements or even trying to understand what customers want, but instead saying that we go about it differently. Like the old saying: "How do you eat an elephant? ... One bite at a time". I have a mantra with my team that I am sure they are very tired of hearing , but is a core part of my ethos: First Make it possible....then make it easy. In other words, your first order of business should be to unblock your customers from achieving their desired outcome, even if it is hard for the customer.
What about make it easy?....slow down there champ, let's cover the first part a little more before we saunter down that aisle together.
Making it possible enables a customer to accomplish the needed with the minimal amount applied from your development team. This sounds just cheap and easy, but don't confuse this with putting out a junk product, or even selling your customers short. This is actually the best way to achieve what is best for both your customers and your development team. Why? This actually follows the first principles of lean startups and applies it to the broader brush of enterprise development. Rephrased: put out very small features, get immediate customer feedback, iterate. This results in the holy grail of enterprise development: moving fast.
I know this is a bit too esoteric for many of you, so let me walk you through an example my team deployed recently. One of my development teams is responsible for Data Lake ingestion and run a collection of ETL flows that allow extracting and transforming customer data into an opinionated data model. One of these connectors hooks into SAP and auto-magically connects about 80% of the base tables needed to run our app, with 20% requiring some form of work needed by a customer. This is due to SAP allowing customers to create Z-tables (aka custom tables) to help run their business and us needing input due to the mult-tenant nature of our app. Our product has a beautiful UX that makes the extractor setup process easy for the respective 'known/standard' SAP tables. Our first release did not have a capability for customers to add in connectors for the custom tables leaving a functional gap. Naturally, product and the engineering team wanted to build a first class experience to add in these custom tables and debate the many nuances of the experience with the next obvious step of writing a BRD. Instead we followed the Make it Possible approach by simply exposing the entire connector configuration as a good 'ole JSON file in the UI. Is it pretty? Nope -- does it get the job done? definitely. In fact, the pretty UX approach would have enabled custom tables, but would have actually limited additional capabilities that were easily enabled with the simple JSON approach. Features like altering the timing of extractions, row-level filtering, etc. These are all available out of the box with JSON, but would require significant effort to expose this granular functionality via UI components. Creating an ugly box on the UX with a JSON configuration allowed our customers to unblock themselves and extract all needed data to power their applications in a couple weeks of dev turn-around versus several months.
Have customer requested an easier UX? Yes.... and I consider that high-praise. This is exactly the problem you want to have! Consider the outcome: You have validated customers are actively using the feature you have built. They are actually using it enough to ask for more. Now we can walk down the path of 'making it easy' Great! Dig in, work with the customers and define the next small addition you will add to make it easier, rinse and repeat. For my Lean Startup readers, you will see how close this is to the exercise of achieving product-market fit. It is very similar, but even if you have hit a good product-market fit, this approach can be used for feature-use-case fit.
It can go the other way, we could have heard crickets: if so, you would have known there is not a lot of interest in that feature of the product and you have invested little. You know better than to chase bad money and as the Beatles say 'Let it Be'. You have learned more about what your customers actually value with little investment -- use your development resources on product your customers care about. If instead you go with the big-bang approach and you get to this spot (very common): you have invested a lot in a feature your customers aren't interested in -- and worse, those resources could have instead built products your customers value.
They say the road to hell is paved with Good Intentions. Consider the fallacy of assumption driven development laid out above. Resist the temptation my friends, come with me and trod down the enlightened path of Making it possible, then making it easy.