Wednesday, November 30, 2011 1:15 PM
Making an SDK Better at its Job
Clay Christensen’s The Innovator’s Solution describes a way think about products, called the jobs-to-be-done framework. Briefly, you look at a product as the job it was hired to do, rather than its category, features, benefits, who bought it, etc. Christensen makes the argument that jobs are enduring over time (as products and customer segments change).
His example is a chain restaurant looking to increase milkshake sales. After using traditional methods and failing, they set out to discover the job that milkshakes are hired for. Here’s Christensen’s account:
The key thing here is that they found a customer segment (morning commuters) that would never have been defined beforehand. Also, the metrics that commuters considered important (long-lasting, quick purchase, fits in cup holder, etc) were nothing like what they would have asked (level of chocolate, healthiness). Jobs-to-be-done points the way to the right innovations for a product to be a better employee at the job it was hired for.
Of course, I want to apply this to Atalasoft and our .NET Imaging SDKs, but SDKs are a weird case. They have to do the job that our customers’ customers want to do (we make tools for toolmakers). If I look at only our customers, I will see jobs that don’t get to the root of the problem.
In this table, the first column is something DotImage does, the second is something that the application using DotImage might use that for, and the final column is the job being done by the user of the application.
|SDK Job ||Application Job ||User Job |
|Turn a Code 39 Barcode into text ||Take a 1000 page TIFF and split it into many documents based on barcodes ||Scan a pile of paper as one document, but have the software know how to split and import it automatically |
|OCR a TIFF and produce a PDF with text ||Scan a document and build a search index of the text in it. ||Find all documents related to a specific customer to comply with an e-Discovery document request. |
|Scan a document from a website and view it ||Import a scanned document into a repository ||Provide ID and other documents when signing up for a bank account |
|Annotate a document ||Provide a document collaboration workflow ||Ask a question about a specific line item in an invoice. |
As you get more to the right side of the table, you start to see enduring jobs – 100 years from now, you’ll have to show ID when you open a bank account, and invoice discrepancies will need to be resolved, and the same was true 100 years ago.
Applying this insight gives SDK makers a way to target features, not at just the job the SDK does for their developer customer, and not just at what their application does, but also at the job that the end-user is trying to do.