I'm a founder of a startup focused on detecting security risks of open source. Because this is a heavily crowded space, what should my MVP contain so as to provide value and test market fit? Advancing the state-of-the-art requires many man-months of effort. Any advice is highly appreciated. Thanks!
> what should my MVP contain so as to provide value and test market fit?
This is a question you should be asking your prospective users/customers. Ask them what they need. If you're charging money, ask them what they'd pay for. If not, ask them what they'd need to see before using your OSS software. I like to frame it as "if I had a product that did this for you right now, would you pull out your credit card and sign up for it today?"
Take what they tell you, look for commonalities and trends, and then use that to determine what should be in your MVP. Build the MVP, go back to the people who would pay for it, and get them to pay for it.
That's generally how you build an MVP (IMO). Though its much harder to do than it sounds.
It may be helpful to shift your perspective from “minimum viable product” to “minimum viable audience.” Who is your first customer? What do they want? Build for them.
Why not just do it manually 20 times first? It'll show you what to look for, what customers want, etc. - and a bit of manual work is cheaper than building the wrong thing.
not sure if thinking of the solution ('advancing the state-of-the-art) is appropriate yet. Two questions to ask yourself:
1)how well do you understand your customers (are you your customer)? Have you talked to at least 10-20 potential customers to understand what their big problems are?
2) Why do you believe that 'advancing the state-of-the-art'
is needed to solve a meaningful problem? Maybe there's an easier problem you can solve for them, use the opportunity to learn and iterate.
Well you might not need to. For example I use both paid github and paid npm. Npm doesn’t offer all the features github does but it does do one thing better (well for now... github are copying them)
Disclaimer: I have zero knowledge of your space and I'm not sure I even understand what you are building. Non the less a few thoughts:
- What is your vision, where do you think things could be improved? Your problem space sounds complex, so I guess it's not simply solved, but you'd have some hint of where you could improve, no? If you found that, try to focus on that. Consider doing a RAT (riskiest assumption test) if you're not sure it can be done or would work at all.
- Can you scope down? I'm totally making things up here, but e.g. just for js warn on npm installs when there is an open security issue on github or something. Or just easy to select newsletters for criticals in a bunch of popular libs. Maybe you can become better than everyone else within that space.
- Be precise on what problem you want to solve and how. I'm not sure yet what you are building after all. You tell my if the open source code I'm currently using is known to be insecure?
- Do you know pain points with current solutions and address them?
Take a look at the breaches of security for open source, was it targeting specific customer data? DDOS? Trying to find specific examples of when it actually happened and then imagine if you could go back in time a month before the breach what would you have built to stop it? That might help you brainstorm.
Are you proposing software to automatically detect flaws? I don't think "minimum security solution" sounds great. Security should be tested per case. I can't see a any software detecting everything without having ridiculous levels of access.
In open source I'd say the main problem is finding someone to pay for it. The only popular tool I'm familiar with (Coverity) makes money from enterprise and does the open source stuff as a form of cheap advertising. There has been a push to pay for more open-source development but it's mostly in the form of bug bounties, so there an MVP would be anything that gets you a bounty.
If it's enterprises using open source then door knocking seems like the best bet; most are still not agile and if you get a need identified you can probably get a prototype done before they send out a bid.
This is a question you should be asking your prospective users/customers. Ask them what they need. If you're charging money, ask them what they'd pay for. If not, ask them what they'd need to see before using your OSS software. I like to frame it as "if I had a product that did this for you right now, would you pull out your credit card and sign up for it today?"
Take what they tell you, look for commonalities and trends, and then use that to determine what should be in your MVP. Build the MVP, go back to the people who would pay for it, and get them to pay for it.
That's generally how you build an MVP (IMO). Though its much harder to do than it sounds.