by jon-wood 8 hours ago
100% this. Go and spend time with the people using your software. Even better, use it yourself.
One of the companies I’ve worked for did food delivery, and in food delivery during Christmas week everybody works operations - either you’re out in a van with one of the regular drivers helping them carry orders that are three times larger than any other week, or you’re handling phone calls and emails to fix whatever problems arise. Either way without fail January every year would see a flurry of low effort/high value updates to the software those parts of the business used. Anything from changing the order of some interactions to fit the flow of dropping a delivery to putting our phone number in the header of every admin page.
Absolutely nothing beats going out there and doing the job to discover where the tools you’re responsible for fall over. Bonus points if you can do it at the most stressful time of year when if anything is going to fail it probably will.
Not using it themselves is why my managment at various companies wouldn't let anyone do sensible things.
Companies that sell to other companies .... don't care about the users. It's one bunch of managers sleezing up to another to make a sale. Whether the product is good to use doesn't matter to them because none of them use it.
A "good" company wouldn't allow this to happen but it happens often enough.
Another bad smell is when developers themselves never use the whole product and simply work on their little bit.
Eat ones own dog-food, or in other words, get the company cooking something great together and sharing the results.
A great company basically opens on its first day and 48 hours later there are a ton of well fed customers who come back, not incidentally, again and again for what they perceive, is great.
But apropos feeding customers, if you can't 'eat your own food' dog or otherwise, why expect the user to want to do it ..
Use it. I agree.
Yep, exactly, and amazing.
And it's such a blind spot in the industry that the people most able to build and estimate features and software are left to be the least equipped to see through the end user's eyes.
As such, when you encourage user oriented engineers, these common and often low effort issues can be avoided at the outset which improves velocity organizationally and results in better software and user experiences for projects now and in the future.