Product Strategy: Flagship + Plugins

[burrrata]

@s_ben

I do like the idea of a core SourceCred product that just work “out of the box”. That’s really powerful. Also, if we’re looking at this from a product angle, to make this financially sustainable we do need “product-market fit”. The lean startup methodology here is proven, and I think makes sense for us. That means putting things out there and seeing what gets actually used, and ultimately what people are willing to pay for. Iterating quickly and not letting scope creep (e.g. building out a whole suite of features and adjacent products that may not gain use) is paramount. This is what a16z (a possible investor) just stressed in a paper they put out a couple days ago, which is a fascinating read generally, and touches on decentralized governance as well.

Andreessen Horowitz – 9 Jan 20

Progressive Decentralization: A Playbook for Building Crypto Applications -…

Crypto founders have to build a product, then give up control to a community of users. Progressive decentralization is the path to success.

That said, I do think we’re not a typical startup in a lot of ways (and I’m glad we’re not). It’s good we’re dogfooding the messy bits too (politics, values, etc.).

Just want to highlight that I strongly support everything said here. Also, thank you so much for sharing that article. I love it

@dillchen

@burrrata where do you see front ends playing in this product strategy? I like the framing around this.

Good point. I mean this really circles back to lots of the questions about who/what is SourceCred for.

• If the target is just creating a tool to measure, manage, and reward open source contributions to git based code bases then just use GitHub and have SourceCred be a backend tool.
• If the goal is to create a distributed protocol that allows anyone anywhere to run pagerank on their things to recognize and reward contributors, then you’d want the protocol to be run on some sort of distributed network and then have open source clients be able to connect to integrate however they want - an ecosystem of modular building blocks that people can assemble around the core SourceCred protocol that computes Cred scores based on data inputs. The core protocol would have a standard UX/UI around a use case (code contributions, forum conversations, etc…). Each of those use cases would have it’s own set of best practices and UI/UX flow. That way it would “just work” for that use case.

Does that kind of answer your question? I think what I’m trying to get to is that the UI/UX should match the use case. The back-end protocol should “just work” across domains, but the way it’s used and how users interact with it needs to be tailored to the audience. The flagship product that works out of the box should be optimized for the highest leverage target audience that SourceCred can provide value to.