Part of the Process

It's a well known phrase with software developers that "naming things is hard", but what about hardware products? What are the worst offenders and how should it be done?  This post was prompted by a couple of social media posts, taking a look at two culprits. The first was camera model names Whoever designed the Canon's camera naming schema deserves a good talking to. Impossible to know what's newer/better, and all the models have multiple names across the world, making searching for info really hard. — Ben Sauer (@bensauer) August 5, 2020 and this one humorously takes a peek at how monitors get their names View this post on Instagram How companies name their Monitors 😂 Via @system32comics Follow @techgang_ for more . . #programmerhumor #gamersofinstagram #gamersunite #gamerslife #programmerlife #codinglife #programming #programmingmemes #codingmemes #computerscience #programmingjokes #computerengineering #workfromhomelife #gamerlife #ga...

It's now about 4 years since I started to think that the "As a ..." user story format wasn't the best starting point for building long running products. One of the things that I found and liked was the jobs story format . The situation When collecting the data I didn't do proper JTBD interviews as such. But I did extract the info from pre-sales calls, product demos, and talking to users. Plus enriching the collected date with the known strategic goals 15below as motivation , i.e. reduce support overhead. I have adapted it a bit and marked it up for our dev teams here. But here is an example for a password reset function. Main thing is that as a B2B supplier we have four distinct groups that could appear in the stories. 15below (us as supplier) as an org,  our clients, their users,  and the client's customers  Here is a simple example for a password reset function all the words in bold are entities that have a defined meaning in a glossary, ...