3 types of product features
Our UX/UI journey is accelerating
We are currently full steam into the development of the initial User Interface for AgileData.io.
The team have done some awesome work on the UX designs for a bunch of the core screens, we have chosen our front end development stack, and built the first lot of backend API’s that we think the front end will need to leverage.
We have started refactoring where we store our magical “config”, which is something we have known we needed to do for a while. The changes will allow us to accelerate the pace we can add new rule types, and deal with even greater levels of data complexity. Starting the development of the UI was the trigger for us to start the refactoring.
As we develop the initial screens we are also exploring the UX design for the next set of screens we need to create, and these screens have an increasing level of complexity that we need to make magically simple.
Less is more
And so we get to the point where as the Chief Product Magician I have to start making trade-off decisions on what features we should and shouldn’t design and build right now.
I am a great fan of the team over at Basecamp (you may know them as 37 Signals) and I have followed the content they have shared in awe over the years, having read the books the team have written such as Rework, multiple times.
From a product design point of view they are big proponents of is less is more technique.
But as the Product Manager / Owner its damn hard to stop yourself adding a feature because you think it should be in the product, even though you can’t really articulate its value to the data user.
3 types of features
To help me with this, I categorise features into 3 types:
These are features where I can clearly articulate how the feature reduces the complexity for the user to manage or access their data.
These are features I know other product in the data space have, and when talking to potential buyers from an organisation they will ask me if we have that feature. I am not really sure how that feature would make a data users life simpler, but I feel I should add it to the product so I can answer yes to the buyer.
These are features that are “hot” in the market and if you don’t have them in your product you are unlikely to get funding from a VC. AI anyone? We are still ok bootstrapping AgileData.io so im ignoring these.
Here is an example of one feature I am struggling with right now.
We have designed and built out the initial Data Catalog screen, so you can view the data that is available within AgileData.io. We are now working on the Catalog Detail screen, enabling a user to drill down on a specific piece of data, and giving them the detailed context they need to understand what the data is and if they should trust it.
Most data catalog tools have a place where you can add and view the data owners for each piece of data. Typically it has the persons name and their avatar. For most of these tools that is all it does, most I say because I know of one that allows the user to add the data to their “shopping cart” and that sends a request off to the specified data owner to allow them to grant access to that data for the user. Cool feature!
Without duplicating that cool feature, we could add a section on the Catalog Detail screen that says “Data Owner” and allow users to add people to that section. But how does that make the data users life simpler? It doesn’t.
So for me this is a buyer feature, something I know I will be asked if we can do it, but I can’t articulate to the AgileData.io team what the value is for an actual user, and so why we should spend time building that versus building something else that has value.
So for now we probably won’t build it.
Experiment to find feature value
Probably because I do have a theory that there is value in being able to quickly see who is an expert for a piece of data.
You know the scenario, where you have to ask lots of people to find out who knows anything about the active customer flag as you would like to use it in some analysis you are doing.
But Im not convinced that manually adding people as a data owner is the way to go, I think there is a way we can make it more magical. And then if we build it as an experiment we will have to see if users actually use it, and get value out of it.
And thats why experimenting with features is just as important as figuring out whether it is user, buyer or investor feature when you prioritise the work to be done.
At AgileData.io we focus on delivering user features, to help Data Magicians rock their data in a magical way.
We are bootstrapping so we don’t care about features a Venture Capitalist needs to give us money, We care about user features that solve customers data problems, so they will give us money for the value we add.
We don’t care about fancy buyer features, nobody will ever use. If the features doesn’t remove complexity for a Data Magician it doesn’t make our priority list.