Thanks, Nick. It is a team initiative most definitely, led in a partnership by someone who’s job it is to study it, think about it, and make it happen.

Here’s a quick and simplified concrete example. We released a sensor not long ago that works with our existing app to pull information about our customers’ vehicle diagnostic codes via the OBD port. We built a feedback loop in the getting started guide to ask why they bought it, and we regularly review the data to see how they’re using it. They told us they want to feel confidence when they go to a mechanic, and the usage data backed that up. So from about a hundred things we could do with that sensor, our top priority became building an easy-to-understand diagnostic code library right in the app.

This involved working with the dev team to get it built against the price/margin point, customer support to understand where the touchpoints and hurdles were for the user, marketing for the definition of the feature and how it changed the product itself, a lot of people. When we do it, how we do it, how we prioritize it, how it reinvents the product, and the responsibility (and hopefully the authority) — that’s on the product engineer. A lot of orgs spread this across different teams today. I see this starting to come together into its own team, populated by people with skills as discussed in the post.