Post by @stani • Hey
Three interesting challenges I want to share from product building perspective that might help other fellow builders here on Lens
1. What are you trying t
Comments
- Completely agree on all points, and I'd emphasize the third point more.
I see so many developers trying to build everything in their app in secret for 6 months. Its much better to build something basic in two weeks then ship and iterate quickly.
- Indeed
- Good tips.
But the problem I generally see is that many founders often "create" problems for their product to solve — building products just for the sake of building, no consideration for how it actually improves/helps users. No innovation at all.
- I Love lens
- #bookmarkAlice
- good
- Excelent tips.
There is a methodology that founders/developers can embrace in order to achieve success with their goals when they create a company/product/software: The Lean Startup. In few words, it treat about to think about and create a Minimum Viable Product, then ask for feedback, add/delete/fix/pivot and repeat.
That way you can create something that can evolve into what your intended public/users really want, and you can achieve great success by creating and giving to your users what they want.
- Agreed 👍
- Agree with that.
- Lens👀
- The real alpha.
- Amen to that @stani.lens!!
Want to add 2 mantras we use a lot at @edenprotocol.lens as well that aligns well with what you're saying:
1. Hack value before you hack growth
Iterate your product to the point of value users have an emotional response when they don't get access to your tool anymore. Once you have that, that's when you can start thinking about how to hack growth. Too often I see founders taking user signups as a measure of success - but if you're unable to keep them engaged or provide value, these users won't come back and mean nothing for your product. This also falls in line with what PG founder of YC talks about when he talks about "do things that don't scale" in his essays.
2. Optimise for speed of iteration rather than speed of delivery
Speed of delivery: "we've just got to get our product out there as fast as possible - Reid Hoffman says that if you're not embarrassed by your first product, you've launched too late" - This results in quick codebase that becomes a monstrosity pretty quickly.
Speed of iteration: "we want to maximize the lessons we're learning so how can we go through a build, measure, learn loop as fast as possible while maximizing the learnings" - This often results in no code at all but finding creative ways of testing assumptions: we have a scale system that we use at @edenprotocol.lens the 5 levels of testing assumptions and we only go to a level 5 after discussing w the whole team - level 1 anyone on the team can do anytime: 1. talk to users, 2. sketch a figma screen 3. create a clickable prototype 4. hack together the feature w existing tools 5. Write the code in no more than 3 days. This is always talked about in light of "is the lesson we're trying to learn from this, worth it.
- gm
- This ☝️
- 💯
- 🙏🏼🙏🏼🙏🏼