When building a new product for a company that has validated idea, there are a few features which are very common no matter what type of product you build - For example, Secure Sign In, Login with [FB,Google,Apple], integrations with X etc.
My question is, how often you look at competitors and see what features they are offering? What is the value of this competitor data to you when making decisions about building features and roadmap?
So these are two different questions. But I think that the only viable answer to both is that whether you're making a decision based on your competitors or something else entorely, you should always use a decision-making framework.
Here's a pretty common framework a PM at Facebook shared at a Product School interview. (You can also read the full article over here: https://bit.ly/33f93ER)
Firstly, work to identify what the criteria for success are. These are what you’ll measure your various options against. The main question you wanna ask is: “If there’s an option that satisfies all criteria, would we be happy with that solution?” If the answer is yes, you got your criteria. I would highly encourage you to validate these criteria with leadership first.
Secondly, map out all the various options that you can think of. If you struggle to find options and can only think of one, think again. Look at the opposite spectrum and then find a 3rd option that is a middle ground.
Assess your options against your criteria. Write a clear explanation of how each option meets your criteria.
Traffic light it! Use 3 colors, red, green, and amber. I normally have the criteria in the columns and the options in the rows so that you have a nice table to color. Make sure that green means good across all criteria, otherwise it’s hard to read
Make a decision, just do it. Make a recommendation based on the colors you identified. Is there a clear decision with all greens? Are there disagreements with other functions that you need to highlight? This is the place to do it.
I assume you have users, then?
>My question is, how often you look at competitors and see what features they are offering
What are your users doing or not doing? Do you talk with your users or provide a way for them to voice frustrations or delight? What are they complaining about frequently? We tend to focus on things that have a higher impact and frequency, just from a development optimization point of view: the backlog is large and we must prioritize somehow.
For example, at some point our users were having trouble training models using the notebooks due to "Out Of Memory". The kernels kept crashing. That is high impact, because there's a loss of work. It's happened to enough people on a regular basis because there was a "tragedy of the commons". After the nth person complains, it was clear what we had to do. Stop everything else, and fix that. We introduced long-running notebooks[0]. This also fixed an issue they were having when a notebook would be running, and users suffered an internet disconnection. The computation would take place in the kernel, but the front-end would not receive the results: this is common in notebooks, and one of the reasons people "save" their models and files. Now even when they disconnect or close their tabs, they can see the output as the notebook is being executed.
Another example: users would ask us for help or ask each other for help to troubleshoot their notebook. They would share screenshots of tracebacks or error messages. We added near real-time editing so people could work on collaborative notebooks, correct each other's mistakes, etc.
We needed to have the finger on the pulse and talk with users (on Slack in our case).
There's a book by Tim Brown titled "Change By Design: How Design Thinking Transforms Organizations and Inspires Innovation"[2]. We built a lot of custom machine learning products for enterprise, and one way to think about this is in terms of "Feasibility, Desirability, Viability". It's pretty useful.
One way to think about it also is in terms of "Jobs to Be Done"[3], with a nice piece by the late Clayton Christensen. What is it your users want to do. This was necessary again in building product because what the customer/client says they need is an implementation of a solution to a problem, not the problem itself. "I want a button to do X" is a solution you must not accept at face value, dig in deeper to find the problem and the job this is trying to do.
One point I'm trying to make is that, granted, some features are required, but it's not really productive to have your product development lead by "competitors". There may be things like best practices, but you must know why you are adding one feature or the other, and it better be something other than "competitor X has it" or a random internet person said it was cool.
You can create issues for them to capture the idea, then discuss it, augment it, and at some point probably kill it. Is that feature really core to your product or is it just a cute butterfly you're chasing.
Also, delegating is not just for people. You also delegate to products or tools. For example, our exercise is a "systems engineering" example. We're not going to reinvent a notebook because JupyterLab does that very well, and in our seven years shipping actual machine learning products for paying customers, we never thought "geez, if only Jupyter had better stylesheets this project would be moving so fast". So we'll limit the scope.
This is similar to Zawinski's "law" of feature creep: "Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can"
Not doing that would send anyone into recursion until they reinvent transistors, semiconductors, atoms, and electroncs. You have to know when/where to stop/start and contain the scope.
>For example, Secure Sign In, Login with [FB,Google,Apple], integrations with X etc.
How many people have asked for that? Why are they asking for it and what do they want to do with it? Is it what's holding the product back? How many are paying for it?
"But... we need that to land enterprise clients". Sure, how many enterprise prospects have you talked with? Have you met them? Did you get only the buyer or those who use it too? Can they try your software and give you feedback without their boss being in the room (assuming this is something old school with a buyer/user dichotomy). Did they say they'd "buy" the software if this feature was there? Did they sign a letter of intent? Is this a peculiarity? You're adding a barbecue to a car. "It'd be great if you could have a barbecue while driving on long trips". This is a caricature, real life is more subtle and these features creep on you until you have a product that's made of pieces of a thousand other products. A monstrosity.
Granted, there are sine qua non features, but you must know these and why they are deal breakers before adding them on.
- [0]: https://iko.ai/docs/notebook/#long-running-notebooks
- [1]: https://iko.ai/docs/notebook/#collaboration
- [2]: https://www.ideo.com/post/change-by-design
- [3]: https://hbr.org/2016/09/know-your-customers-jobs-to-be-done
