Learning a framework or tool and shipping your product are two things that don't really mix up most of the time. In this article, I explain why you should separate the two for your project
Shipping Product 🚀
I have a strong belief that when your goal is to ship your MVP a la The Lean Startup, you need to use tools and techniques that you are familiar and comfortable with. That way, you can focus on creating the MVP and generating value.
The focus needs to be on the product level, meaning that everything you're doing is about thinking:
- how will this add to the value creation for the end-users?
- is this feature necessary, or can I do this in the next version?
- does the feature feel natural, and is it easy to use for the users?
- etc.
How you actually implement your project using (no-/low-)code, and if it is the neatest way to code it are not as important when you want to provide value without investing too much time and effort which results in a longer time-to-market.
Not when you're bootstrapping your product/service, and want to ship your product within a short timespan.
Learning The Tools 🎓
If you're working on a side project to learn a framework, stack, tool, whatever, it's best when you're not committing yourself to a stressful deadline. You can focus on learning the tools and choose simple tasks or projects to create so they can be realized within days or weeks.
Trying out variations and different approaches on how to create things with a framework really lets you get your hands in the code and often shows aspects and use-cases that are helpful later on.
Mixing Learning & Shipping
What you need to understand, is that when you're using tools/frameworks/.. for a product that you want to ship that you didn't use before, there is a great chance that this will stall your progress.
You'll most likely bump into an aspect that you want - ney..need (it's an MVP, right?) - to implement but then, when you're actually using it, you find yourself spending hours on figuring out how to get this small thing to work for your project.
Perhaps you even are the lucky one finding out there is a bug in that one feature that you need for your use-case that was going to save you a lot of time... 🙈
Nothing is more frustrating than finding yourself stuck or delayed because you assumed that a library would do the trick.
After developing for over 20 years I know that these scenarios are inevitable, but minimizing the risk of this happening and getting stuck less, can really mean the difference between "being in a happy flow working and getting enough progress to keep at it" and "getting stuck too many times and dwindling off to your next thing".
This is where the perseverance and consistency part for makers kicks in.
Investigate Upfront 🧐
In my experience, the only way to properly integrate something that's "new to you" in a product that needs shipping ASAP, is to find something upfront and research it before you start your product.
Researching means going over the website, Googling, and reading user scenarios on sites like Stack overflow. Finding out if the product is actually working and if there are people around that can help you.
Support & Community Matter 🤝
By making sure that the product is well supported and maintained you can be more assured that this will save you time, not cost you time.
Often, there are commercial products that will cost a little but that have proper support and guidance for your situation, which might give you more assurance that it will actually function.
When it comes to using open source, finding out if there is a vibrant community of users and demos for use cases or issue discussions can be a sign that it will help you out on creating and shipping your product.
Especially when you're implementing an edge-case that hasn't been implemented many times before, knowing that the creators, maintainers, or users of a framework or tool can help you out can be the life-changing fact you need.
Concluding 🏁
By now, I hope I've shown you why shipping and learning don't really blend well if you want to ship your MVP and get it out there using minimal effort on a strict deadline.
Here are the key take-aways I want you to remember:
- Don't learn implementing something on the job if you want to ship your MVP anytime fast
- Use frameworks, tools, and code that you are familiar with
- If you need to use something for your project, research upfront if it has proven to be useful for your use-case and check if support and/or a vibrant community are around
Either code to learn or code to ship. Or first code to learn, then use what you've learned to use that in something to ship.
Working with the things you are familiar with really helps to keep the pace, focus on shaping the right product, and will reduce the number of times you will get stuck during the implementation phase.
And it will prevent me from having to tell you that wildly annoying but famous phrase:
👨🏻🏫 I told you so ☝🏻
Code Hard, Ship Harder 🔥
This article is also published on Medium
Top comments (0)