3 ms·

Time to market tends to dominate most conversations around planning, but as I look back on a 10 year stint that I recently finished with a company, I am firmly

Time to market tends to dominate most conversations around planning, but as I look back on a 10 year stint that I recently finished with a company, I am firmly convinced that this is the wrong strategy. Time and time again, I saw teams making compromises and taking shortcuts to shave a week off of a project timeline—only to have a crummy and bug laden release create negative first impressions with our customers. Many features were poorly validated for market fit and were sunset just a year or two after release, as the maintenance cost outweighed value. My (admittedly biased) opinion is that the best way to deliver value to a business is to spent a lot of time and energy figuring out what your customers actually want, which is usually just a few key things, and then take the time to build those features the right way (less time pressure because the surface area is smaller). This lowers the ongoing maintenance cost, as the team has the time necessary to do the work properly, and increases CSAT and retention. When it is time to build something new, the team isn’t so bogged down with maintenance and debt, so they can focus more directly on the problem in front of them. Sadly, it rarely seems to go this way.

kqr 4y ago
> My (admittedly biased) opinion is that the best way to deliver value to a business is to spent a lot of time and energy figuring out what your customers actually want, which is usually just a few key things, and then take the time to build those features the right way (less time pressure because the surface area is smaller). I'm of the exact opposite opinion, but we agree on almost everything, funnily enough! I think the best way to deliver value is to quickly write small, fast, rock-solid but relatively un-featured prototypes and see in which direction production feedback indicates you should evolve those. The above is based on two things: 1. You can't know what your customers want because not even your customers know what they want. They only know what they don't want once they see it. You can spend a lot of time an money on research but the MVP is cheaper and a stronger signal. 2. The same idea you put out there: most things are bad market fits and should be sunset fairly quickly. By building small things, you optimise for this case. By also making them reliable, you don't make it too painful to evolve them later on. (Easier to add features to quality software than add quality to featureful software.) This, of course, also leads to less maintenance and higher pace of innovation down the road!
- arminiusreturns 4y ago
  This is why many of us ops types are annoyed at the current popular fad of rejecting the unix philosophy of keeping programs small and task oriented, but able to pipe and be piped as part of a greater workflow putting those things together. This is exactly it. I see whole stacks, and theres seems to be always a key app or microservice or two written by a particular team, and it usually: has bad log formatting, doesnt multi-thread or muli-task well (concurrency and parallelism), have some non-standard or extranneous db or rpc/api queries that impact entire flow with locking, etc... If the focus was to make sure the services were rock solid and that was the focus it saves so much future pain and tech debt digging. On note of what the customers want: I think the approach I prefer is to not spend much time on it, and make it fast and intuitive - quick brainstorming brings rawer truths to the surface often if done frankly. Alas, all that said, one can't always manage upwards. The c-suite and the boards are so often high on their own airs they stop listening to engineers or have let the wrong ones become filters, and there is nothing you can do to change that unless you are on the board and can fight at that level, but I don't know many engineers that can. This is the main irony of SV to me.

kqr 4y ago

> My (admittedly biased) opinion is that the best way to deliver value to a business is to spent a lot of time and energy figuring out what your customers actually want, which is usually just a few key things, and then take the time to build those features the right way (less time pressure because the surface area is smaller). I'm of the exact opposite opinion, but we agree on almost everything, funnily enough! I think the best way to deliver value is to quickly write small, fast, rock-solid but relatively un-featured prototypes and see in which direction production feedback indicates you should evolve those. The above is based on two things: 1. You can't know what your customers want because not even your customers know what they want. They only know what they don't want once they see it. You can spend a lot of time an money on research but the MVP is cheaper and a stronger signal. 2. The same idea you put out there: most things are bad market fits and should be sunset fairly quickly. By building small things, you optimise for this case. By also making them reliable, you don't make it too painful to evolve them later on. (Easier to add features to quality software than add quality to featureful software.) This, of course, also leads to less maintenance and higher pace of innovation down the road!

arminiusreturns 4y ago
This is why many of us ops types are annoyed at the current popular fad of rejecting the unix philosophy of keeping programs small and task oriented, but able to pipe and be piped as part of a greater workflow putting those things together. This is exactly it. I see whole stacks, and theres seems to be always a key app or microservice or two written by a particular team, and it usually: has bad log formatting, doesnt multi-thread or muli-task well (concurrency and parallelism), have some non-standard or extranneous db or rpc/api queries that impact entire flow with locking, etc... If the focus was to make sure the services were rock solid and that was the focus it saves so much future pain and tech debt digging. On note of what the customers want: I think the approach I prefer is to not spend much time on it, and make it fast and intuitive - quick brainstorming brings rawer truths to the surface often if done frankly. Alas, all that said, one can't always manage upwards. The c-suite and the boards are so often high on their own airs they stop listening to engineers or have let the wrong ones become filters, and there is nothing you can do to change that unless you are on the board and can fight at that level, but I don't know many engineers that can. This is the main irony of SV to me.