When building something, focus on truly creating an impact before releasing and refining it.
Then, consider focusing on other impactful work before refining your prior releases.
Here is a simple test to see if you're building something impactful: Can you write a blog post about what you're releasing and how it will change your target customers' lives? If you are shipping something that solves a problem for a customer, it would probably do really well. But if you're merely adding some small changes / additions to an existing feature, it probably won't make for an interesting read - failing the test.
<aside> 💡 Some bug fixes are impactful, but none deserve a blog post.
</aside>
There is a natural tendency of teams to relax or switch gears after shipping something impactful. "Phew, we did the impactful thing, now let's work on refinement". You should counter-act this notion, and continue to focus on building impactful things.
When the impactful work you've released is sufficiently used by customers, the refinements become impactful work in themselves. Keep shipping.
<aside> 💡 Impactful work is work that creates value. Work that creates value is impact.
</aside>
Customers must love your products. If they don’t, work until they do.
It’s a mistake to think you need to have someone do research for this. Just speak to a few of your most active users. Then address the things that will make them love your product. Small, incremental changes rarely make someone go from a 3/5 to a 5/5. It's the highly impactful things that move the needle.
Highly impactful things aren’t necessarily a large amount of work. They also don’t stop you from working in quick iterations based on user feedback. But there is an anti-pattern to avoid here: Do not split products in advance into ‘v1’ ‘v2’ etc. This is iteration theatre: you’re not actually listening to feedback to decide what v2 should be. A better approach is to ship the first great version and start to work on the next most impactful thing. Then user feedback can drive a true ‘v2’.
When you’re done with that, do impactful work to gain more customers. Rinse and repeat.
Only at scale, where you have many (1000s) of customers using your product regularly and generally giving you positive anecdotes, does it become valuable to do more structured research and e.g. getting an NPS score for your product. Below that, rely on just talking to people and shipping things.
If your team is called "Authentication", then it makes sense to worry mostly about adding and supporting authentication methods. But if everything up to the point of authentication is broken - no one will appreciate your hard work. You are stuck in a local maximum - and probably believe you're doing the right thing. You are not.
Be proactive and decisive. If something is broken, fix it. If there's a need, address it. Let common sense and first principles guide you when you're unsure. But don't be timid be brave.
The name of your team is a direction, not a path. You should aim at maximum impact to the customer. For example, if you find that fixing something in the sign-up flow makes more people use your authentication methods, and you believe the impact of this is larger than any other work you could do, then you must fix the sign-up flow.
Whenever I spent time reviewing roadmaps, I didn't think "How can we do more within Authentication?", instead I thought "Given the unique capabilities of this team, how can we have a maximum positive impact on the customer?". Generally, we believe that we did an OK job naming teams according to what we believe our priorities should be - but that exercise was done ONCE, and in the past. If we were honest, we should probably rename every team, every two weeks or so.