Sunday, April 17, 2022

Gambling or Groceries?



Following on the post about sustaining software, here’s an opposing argument. 

Go big or go home. Deliver shocking value. Focus attention on exponential results instead of linear ones. Leverage your investment into the biggest possible return.

All of those exciting phrases are exciting because they mean increasing risk. Some are drawn to that risk, preferring to be a dead eagle than a live turkey. “No one ever achieved greatness by playing it safe” said Harry Gray. There’s truth to this statement: taking risk does not guarantee a reward, but a high degree of risk avoidance can guarantee the absence of reward.

And so, the question becomes how to balance pursuit of risk against safe bets, which luckily is the sort of thing that businesses have been thinking about for a long time. Unfortunately, some of the tools available to the finance department may not work as well for a product team. For instance, diverse asset allocation makes a ton of sense for a financial advisor, and is a legitimate company goal up to the point of market saturation, but becomes less great when you’re spreading your development efforts across unique and unrelated product efforts. The essence of strategy is making choices, after all, and it's potentially hard to be unified behind a single strategy as well as diversified in your investments. Still, the idea of isolating risk budget from non-risk budget has merit.

Therefore we think of gambling versus groceries, or more prosaically, Research and Development. The gambling side of the house does research into ideas that become new products, and the groceries side of the house develops and maintains the products that already exist. A very sensible model, but one that has been known to produce a house divided. If internal political pressures or external market drivers shift an R&D organization into full groceries or full gambling, then another organization will most likely be formed or funded to solve the other need.

Saturday, April 16, 2022

When to use Design Discovery Patterns


 

People love one size fits all patterns and models, but it is usually better to use the correct tool for the job at hand.

So you need to solve a problem. You’re going to build a solution to solve the problem with. It’s going to have users, who will configure it, give it their problems, and get solutions out of it. You’ve written some product requirements, you’ve got personas, you’ve got ideas. Then you start talking with other people and are faced with a dilemma:

* Do you Double Diamond explore the whole space of potential?

* Or do you “thin steel thread” to a Minimum Viable Product, then expand as demand drives?

The designer: “You’re suggesting an approach that covers left-to-right languages, but I see in your meeting notes that some of your customers do have operations in countries with right-to-left languages, and are you sure you won’t have need for that some day?” 

The architect: “I see you’re thinking under a dozen simultaneous admin-level users but are you sure it won’t need to be architected for thousands?” 

The engineering manager: “There’s an export data function here, what if instead of raw data dump we support PDF with an accessible color template?”

This is double-diamond thinking, and each of those ideas represents a quarter of work that you didn’t account for in your timeline.

Alternatively, the project manager comes in with “why don’t we do a non-working prototype and see what people do with it?”

And the team lead suggests: “if we constrain to a single type of conversion, we could get this done by end of the quarter.”

This is thin steel thread, developing an MVP (Minimum Viable Product), and each of those ideas is removing a big chunk of what you wanted from the first release (in the non-working case, the chunk is “everything”). Digression: a popular model for explaining MVP is the “from scooter to bike to car” blog post — which I have to say I hate, because it’s not an effective metaphor. Making and selling physical objects that don’t optimally solve a problem is tremendously wasteful, especially if you take the problems of disposal into account. Making and selling software that doesn’t optimally solve a problem is considerably less wasteful. The problem is that while software ages like milk, the cost of producing it is considerably more expensive than milking a cow.

All that said, the George Box quote that “all models are wrong, some are useful" is certainly applicable here. Both models are the right choice at different times, and the distinction is in whether your development team has the right tools in their bench for solving the problem that needs solving. 

To do the thin steel thread trick efficiently, you need to be using off the shelf components. It doesn’t matter if they are in house or OEM or open source, it only matters if your dev team is knowledgeable and comfortable with the components. If the engineers aren’t using tools that they’re comfortable with, then they aren’t able to efficiently produce successful solutions to problems. So, first job is to get the toolbox you’ll need, and that’s a double diamond job. In order to build or select and learn a good set of tools, you have to know the whole problem space that you’re going to work in.

A second factor that leads to is domain expertise, which can be a product manager’s problem. Developers spend a lot of time learning software engineering, and not the problem space that your customer is trying to buy a solution for. The purpose of these design discovery patterns is to build a minimum level of expertise in the domain, sufficient to produce useful software tools. Like any tool, they are limited to the use case that their designer intended (consciously or otherwise) and may not function properly in others scenarios.