Comments on Lessons Learned: Revisiting the Software Design Manifesto (and what...

One reason to distinguish between technical design...

2009-08-10T00:13:34.595-07:00

One reason to distinguish between technical design and product design is that technical debt and product debt are different. The problem with the minimum viable product is that it has product debt: some absence of features, functionality, usability, polish, whatever. With technical debt, you pay the interest. With product debt, your users pay the interest. And compared to technical debt, the impact of product debt is much harder to measure. There's lots of information about performance and metrics out there, as well as a peer expectation that being concerned about those things is an important part of being a competent engineer.

But product debt doesn't have this focus. I think the interest in quick and easy usability testing (avoids time/money being redirected away from engineering concerns), and split-testing (often misused to simplify product design decisions to binaries) are signs of the problem, not the solution.

But what if the solution is staring us in the face? If rapid iteration and feedback is desired, why not iterate on throw-away prototypes that are trivial to produce and incur zero technical debt? This seems to be what SBCE points us to: considering a broad range of design options with enough fidelity to a real product to get useful feedback. Jeff Hawkins, the inventor of the Palm Pilot is said to have carried a block of wood around in his shirt pocket for a week to validate the concept.

This isn't a very popular option because it runs counter to common engineering intuitions (or are they taboos?). Prototypes are easy to build and meant to be thrown away, which violates the intuition that engineers have that value is created by building things to last and doing things that are (technically) difficult. Incidentally, these also seem to be the same intuitions that lead to the typical attitude to technical debt. Perhaps this is a bit too provocative, but what if this means that getting past those taboos requires abandoning one's identity as an engineer?

Customer Development is itself an example of SBCE....

2009-08-09T10:02:49.669-07:00

Customer Development is itself an example of SBCE. The way I translate it into the lean startup framework is to have a separate problem team and solution team - that work concurrently to shape the product that the company will ultimately build.

They key to understanding how to translate these traditional product development or manufacturing processes into a startup context is to remember that startups break down the traditional barriers between departments. There is not "just product development" in a startup - the context of extreme uncertainty that we operate in means that every choice we make impacts the whole company.

"Returning to the subject of technical design, thi...

2009-08-09T02:54:45.310-07:00

"Returning to the subject of technical design, this yields a new criteria for a good dynamic technical design. It should still be Firm, and still promote Delight for our current customers. But it should also be resilient to changes in purpose, even dramatic ones"

I think that's spot on especially if we qualify exactly what "resilient to changes" means. A common interpretation would be endless flexibility in a design which leads to gold plating etc. In contrast we require a well partitioned design with appropriate levels of coupling and cohesion etc.

Just wondering if we could summarise the overall theme with a variation on "No battle plan survives contact with the enemy" (Moltke):

"No design survives contact with the customer"

Thus we should plan accordingly...

Are there examples of using Set Based Concurrent E...

2009-08-08T17:04:22.039-07:00

Are there examples of using Set Based Concurrent Engineering (SBCE) productively in the customer discovery phase of a startup?

SBCE feels like it should fit into the lean startup nicely, but I can't quite figure out how. Lets accept the idea that the unit of progress for a startup is the customer-fact. How does Set Based Concurrent Engineering help?

Toyota uses it as a purely technical process. No customer is asked if they like the bigger battery but heavier hybrid or smaller battery and lighter car. The engineers making those decisions are bathed in customer knowledge but the decisions are made on a technical basis. There is no iteration in the process, in fact the SBCE serves to remove iterations (rework).

I guess the crux of the problem is SBCE gives you a quicker path to a better solution of a known problem. But in the early stages of a startup you are still trying to hone in on what exactly the problem is. No?

One place I can see the benefit of SBCE is by rubbing alternative designs against each other you should be able to discover what your unconscious assumptions are. How else can it be used?

gr8 blog. it is very helpful for me. Thanks for sh...

2009-08-08T06:08:19.649-07:00

gr8 blog. it is very helpful for me. Thanks for sharing this.