There’s a great new post over on Paul Young’s Product Beautiful blog covering the pitfalls and success factors of creating a platform-style product. Paul notes that “Platform programs are dangerous because they are usually under-stated in time and resource commits – they have the potential to touch every part of your existing spaghetti code. The urge in the development team to re-architect during a platform build is irresistible. “ I wholeheartedly agree, having played a lead product management role during the development of the Softimage|XSI SDK and having designed several versions of the 3rd party developer program.
In the case of XSI, the SDK was initially intended as a way for customers to integrate it into their production pipelines and more easily develop their own automation and deploy versioning / asset management into the application. For that reason we initially felt that the APIs could be quite limited in scope and didn’t need to be a true reflection of the (somewhat squirrelly) internals. How wrong we were. As soon as they got hold of it, customers wanted to hack the app, and add their own tools and features. It took a further ten man-years of development to bring the APIs into line with customer needs, and involved signficant internal cleanup to get it there.
Our mistake was to rely on the needs customers that screamed loudly in the assumption that they offered a set of requirements that were valid across the industry – and also that these customers knew what they wanted and would ask for it. We should have invested more time in planning the SDK based on a better market sampling, observation-based data (as opposed to customer requests) and more thorough analysis.
