Brett Sandusky is a maker of things, both digital and physical. He is the founder of bdigitil Media Labs, a consultancy which provides UX, product development services, physical and digital prototypes, and strategy assistance to companies launching new ventures. On September 25th, he’ll be our speaker at BookMachine New York. We wanted to find out more.
1) Tell us about ‘bdigitl’. How do you work with publishers?
was originally set up as a consulting business to work with publishers and media companies on incubating and launching new products in the digital space. Typically, we work with clients on user experience and interaction design as well as offering guidance and recommendations on how to handle development, for example. Since its inception, the goal has been to be extremely focused on building high quality products. Our own evolution as a company has also seen us grow to include a variety of services from web application development to 3D printing. Still, our focus is on the product; whatever that product output may be.
The process of building products in the digital space is, for many publishers, very different than the workflows with which we are most comfortable. The process of building a digital product, whether that’s an ebook, a website, or an application of some sort, brings its own set of best practices, documentation, and workflows. In the print paradigm, printer-ready files are an example of this: an inevitable byproduct of the process that is, at this point, created without second thought. Because of this extra baggage, it is often challenging, though not impossible, to shift from one mode to the other. bdigitl’s role, within that interplay, is to help guide companies in decision-making, conceptualization, design, and development of products with which they may not be as familiar.
Ultimately, we aim to help our clients to understand the implications of the decisions they make concerning the end product. Just as the type of paper used for printing can affect both the bottom line and the user experience of reading a book, a seemingly small interface decision can do the same in the digital realm.
2) Publishers are starting to understand the importance of SEO. To what extent can SEO be implemented? Do you envisage a future where the decisions of IP creators will be affected by the rules of SEO?
For a long time now, I have been of two minds concerning SEO. One one hand, it is an inevitable responsibility of any digital object to be findable. And SEO is certainly the best way to make something findable on the web. On the other hand, it’s hard, in certain circumstances, to envision SEO changing certain types of content. Fiction is a perfect example.
I feel it would be difficult to tell an author of fiction, whose job it is to craft words as an artform, that she needs to output SEO friendly content. It may also not be in our best interest to do this anyway.
Right now, I think the best opportunity for publishers in regards to SEO is in metadata. Exposing the highest amount of rich metadata and allowing that information to be indexed and searched is a major win for publishers.
3) Last year at TOC you talked about ‘Agile Publishing’, as the new path for content providers. How important is collaboration to agile publishing?
Agile is, at its core, a framework for working in collaborative structures efficiently and effectively. Unless you are some sort of anti-social, one-person startup, no one builds a product in a vacuum. Everything we use, do, experience, and interact with is a product of collaboration.
What agile teaches us is how to interact in a small, collaborative “pod” to output the best product in the most efficient manner. It’s an approach that has been used for many years in the software development world, and every digital product is, no matter how big or small, a piece of software.
For years, publishers have had a workflow whereby they create a number of documents and assets, compile them, review and edit them, and then ship them off to the printer. The documents the printer receives, along with any additional instructions, let the printer know exactly how to execute the manufacture of the book-object.
This is not very different from building digital products. The developer takes the place of the printer and executes on the manufacture. And there is typically a product team to plan and create the documents to “ship” to the developer.
What many people don’t think about is the sheer amount of possibilities that need to be decided upon from a product perspective. With printing, we are often, through financial constraint, tied to a subset of options between which we can choose. Whereas using colored paper may cost more than white, there is no cost to this elements on a digital property.
The point is that agile helps us, as product developers, approach this situation and others like it so we can address all the issues we need to in order to ensure a smooth and productive process.
4) You relate the concept of agile publishing to new modular businesses – how does this work?
The agile approach is modular. Software, when done right, is modular. As such, it should make sense that our businesses are modular as well.
Often, business models are rigid, particularly in legacy industries like publishing, even when the product and sales realities have radically changed. We’re all familiar with the old-school editorial P&L. But, the elements that contribute to determining a salable product within that system do not necessarily apply to digital products. Even digital versions of the same products.
Essentially, I have long advocated for having a more fluid set of modular business models, each that applies to the different product realities created by a company. Since agile is already accustomed to dealing with a separate set of requirements for each product, it seems an apt analogy.
5) Data analysis seems to be key to the success of marketing operations. Do you have any advice for publishers looking to improve in this area?
Metadata. The key to data compilation and analysis is metadata.
In the world of data analysis for publishers, there are two bits of really important information. The first is that we are handing off our products to retailers (who also own the devices used for consumption of the product) and not demanding they share user behavioral data with us. As such, we lose control of that important piece of information that could inform our product development cycles if we had access to it.
The second is that you have to put out data to be able to analyze it. Actionable data does not just materialize in the ether, unfortunately. For publishers, under the current paradigm, that data is more or less relegated to metadata that we can control. But, without taking an active role in developing that data and planning out its use and analysis, the power of using it is essentially lost.
6) Lastly, when you talk about product development, do you refer to your passion for knitting?
Haha! I’m actually glad you brought that up. Agile product development and knitting are very similar in approach. Before one begins to knit an object, there is typically a pattern, with the plans for making whatever it is that you want to make. These are the blueprints needed to make sure your sweater or socks or gloves will fit once they’re done.
The same holds for product development. It’s all about the passion of building something from nothing.
If you have enjoyed this interview with Brett and want to hear more about the way he works with publishers, then you can hear Brett speak at BookMachine New York – get your tickets here.