Shipping faster 🚢
Time to market is really important when developing a new product, or feature. Delaying your release usually brings more pain than shipping something not fully refined, and iterating over it.
That's why most successful teams usually ship fast, but then iterate even faster. The key here is on shipping the right thing initially, which will gain you the market so then you can iterate on actual users' feedback.
How do you define something as shippable?
One of the main problems when trying to ship fast is how you flag something as shippable. You can easily fall into a pit of reiterating internally and never ship anything.
Everything starts with the problem definition, you need to be able to define your problem in a way that it's easy to say when it's solved. Ideally, you should define it in a way that you can check boxes and once all boxes are checked, then the problem is solved.
When defining the problem, and what needs to happen in order to have it solved, you need to abstract yourself from the solution. Think about what the users should/shouldn't be able to do. And don't be afraid on being too strict on what means to have the problem solved.
Common understanding across the teams
It's important that everyone is on the same page regarding when something can be shipped. This means getting everybody's buy-in on the problem definition, that's why usually the crafting of this list that determines a problem being solved is a collaborative effort across different teams.
It's equally important to have a clear vision and next steps, even when everybody agrees on what needs to be done to ship, it must be clear if there will be next steps, and their priority.
Define what you wanna get from shipping now
When shipping, you must also have certainty on what's your goal. Beyond solving the initial problem, is there something else you want to clear out? It can change from ship to ship.
You might want to test an assumption, check usage data, or even learn how users interact with certain kinds of features to define monetization or challenge your current roadmap.
By having this clear, you can also get a reduced set of users you want to ship first to. Here's the time to play with some smart rollouts trying to minimize the risk, while maximizing the learning when shipping something that you don't have full certainty about.
Iterating over the initial ship
Being ready to iterate is important, that's why you need to have clear feedback channels for your users. Also, you need to follow closely all the feedback from your users, and take it as input when iterating.
Something that should be always clear is what's the value of the initial ship, and how it solves a problem. You need to overline its value and make clear that future iterations will add on top of it. But also be ready to rescope some stuff that maybe was not well defined or is not actually solving the problem.
Don't forget to also set up monitoring where you can keep track of vitals, it's important to track relevant information that will also be valuable input for future iterations. These metrics should be related to the problem, and not to the usage of your solution.