Great piece, Ash. Definitions are important for alignment. We struggle with defining (individually) when we don’t understand. If people are comfortable and confident in skills and knowledge, defining becomes less fraught with “what’s a …”
Thanks for this Ash - I'd even go a step further and say it's actively harmful to try and define a data product with a laundry list of technical specifications around concepts like interoperability, self-documentation, or other standards.
At its core, a product is defined by being *of value* to its customers & consumers. For some customers or use cases, that value will require interoperability, extensibility, or whatever other technical attribute someone's decided is "defining" of a data product. For others, sending over a .csv file over email is more than sufficient to deliver value.
Great piece, Ash. Definitions are important for alignment. We struggle with defining (individually) when we don’t understand. If people are comfortable and confident in skills and knowledge, defining becomes less fraught with “what’s a …”
Seems like tech professionals need a resume translator to always choose the hottest buzzword for each term.
Thanks for this Ash - I'd even go a step further and say it's actively harmful to try and define a data product with a laundry list of technical specifications around concepts like interoperability, self-documentation, or other standards.
At its core, a product is defined by being *of value* to its customers & consumers. For some customers or use cases, that value will require interoperability, extensibility, or whatever other technical attribute someone's decided is "defining" of a data product. For others, sending over a .csv file over email is more than sufficient to deliver value.
Outcome > output
Value > specification