When Scoping Doesn’t Happen
I was a little too trusting. And I regret it. Normally I’m an overly suspicious PM who does lots of due diligence when saying yes to a product development project.
This time I messed up. And I had to own up to it and do some damage control. So what happened?
My company uses a taxonomy, as do most tech companies that rely on SEO. This taxonomy is critical for many business decisions and drives some of the customer experience.
That’s the thing about data. Once good data gets into a digital ecosystem, everyone wants to use it. So if I had to guess, there are around 40 downstream teams that use this data at my company. And that’s just internally.
AND it’s applied in the product I manage.
With that being said, I thought a minor change to the taxonomy would be negligible. The request came from the vocabulary, taxonomy, and ontology team that owns the legal list of terms and schema. So…like a naive son of a gun… I said yes to the request to simplify the UI. I assumed that the VTO team had done scoping. They did, but not to the depth that was needed to confidently make this change.
Essentially, the schema in the UI would go from a 3 level structure down to a single level point of data. In the backend, the intent was to attach the hidden tendrils to each branch.
Side bar: If you’re not familiar with taxonomies, this is probably a bunch of jibberish. But you can think of it as a list of terms that helps to organize a collection of data.
The original design and functionality in the UI for the application of the taxonomy required joining of several tables in the code. But when the VTO team requested the single data point, I went forward and told my engineers to rip out the more complex code and only use the single table.
Fast forward to a demo with some executives. I showed them the functionality thinking they would be excited by the notion that their employees (my users) would not have a high cognitive load as they are creating their instructional design. This functionality simplified the user experience. But to my dismay, they balked at the idea and said a lot of things like, “I’m afraid this will impact ABC.”
While it did simplify the user experience, it also could potentially significantly impact a machine learning model. This would translate to our company losing thousands upon thousands of dollars.
Fortunately, we hadn’t released the feature. I ALWAYS demo something prior to release if it is a major update to the UI. And thankfully the executives spoke up.
This led me to do additional investigation which gave my team and I some options. However, it wasn’t easy telling the poor engineer who worked so tirelessly on this project that she would likely have to revert her changes. And we were hoping to have this out by the end of the year. It’s not happening. (Cue the downer trombone music. )
It sucks. That’s the reality of being a product manager, though. Sometimes we fail. And we have to own that failure.
But we live to see another day. Or another feature release.
