Comment by Stroemgren

Thanks for sharing this. It’s really appreciated.

I’m very much on board with the “thinking it as a product” and I think we’re actually going to be in good position to sell it to other teams since they’re being forced to adhere to common designs - there’s just no help or implementations to get them there. So even if we don’t build something they find as good as their favorite library, we’ll have the upside of being the one that adheres to the design.

I also like your thoughts on “customer support” and I’m considering whether doing hands on help for the teams migrating would also be worth it.

I’m still pondering whether starting with something really hard or doing some of the easy stuff is the right way. Starting with easier stuff would allow us to build a foundation, get to the point where the library is actually installed across products, which could help establish some feedback loops. That said, I really like your point about targeting the most legacy apps. As you say, that might create of following of people that appreciate the work and would spread the word.

> since they're being forced to

Be careful with wording things that way. "There's currently no competition" and "you have to do it anyway" isn't necessarily a product feature, but possibly a reason to be distrustful.

But yes, ease of use should be easier to sell given a status quo with no competition and no existing easy options.

> I’m still pondering whether starting with something really hard or doing some of the easy stuff is the right way.

It's always going to be a hard decision. It can be helpful to bootstrap with the easy projects with simple needs and by volume (raw number of projects) there might be more of them, but when you finally get around to the hard projects you find you didn't prepare enough and need a lot more work, or big rewrites that will upset all your "easy" customers. But, yes, if you start with the hard projects (and those might be by volume the company's largest codebases or user bases) you might see a lot slower progress, a lot slower to get to an "MVP" point, and subsequently a lot slower to establish some of your feedback cycles, but the teams giving you feedback are likely ones that are going to be most appreciative of the hard work, most helpful in helping getting the easy things rock solid while also given you a perspective on the hardest things, and can be indeed be your greatest internal marketers to other teams if they are happy with all of that hard work.