or subscribe with
Join 3,400+ readers for one email each week.
Digests » 41
this week's favorite
Through my years as a manager, I’ve been fortunate to work with truly amazing folks. I can count the number of people I’ve dreaded having 1:1s with on one hand.
What is the right way to build products? Earlier in my career, I would have told you everything should be AB tested, and that you should build only as little as you need to validate a hypothesis. Every problem should have user research involved at the beginning, aligned on the problem instead of just validating or invalidating solutions. Every key result should be outcome based. Every engineer, designer and product manager on the team should be involved in defining the problem and the solution. These are all good ideas. However, once you add enough of these “best practices” up, it reads kind of like those articles talking about the morning habits of the most successful people in the world. If you actually try to follow all of those habits, it would take you six hours a day and cost a lot of money. I was once reading an article about what a futurist at Google eats for breakfast every morning to live longer. The article added up that his diet of food and pills cost him $1 million per year. My morning ain’t that long, and I ain’t got that much money.
By “high growth”, I mean in terms of employee count and roughly doubling or more every year. Even at slower growth rates, some of the phenomena I’ll describe may be relevant.
Last time, I explained that, although estimating software project timelines is hard, you should do it anyway. With that background, I want to go into some detail and share the technique I use when I need to develop a project timeline.
In most organizations, if there's a Product Owner, the dev team is generally subservient to it and charged with building whatever the Product Owner comes up with. That's not to say they aren't often "on the same team", but the flow of responsibility is usually the PO pushes new requirements and the developers respond to them. Sometimes this relationship, even if only implied, has ramifications for the developers.