Outside-In Software Development: First Look

A first look at Outside-in Software Development, available tomorrow (or pre-order tonight on Amazon.com). At the time of this writing, the book is #29 on the Hot New Releases list – and you can get it for just over a third off the price if you pre-order now. Take a look at an overview of the book and our first impressions – then give the book a bump and let the wisdom of crowds take over.

Anticipation and Excitement

You usually aren’t excited about a business book, or a software book, when you open it for the first time. Something is different about Outside-In Software Development, because I got very excited as soon as I saw what the book is about. It’s about the hard part of goal driven development – understanding the goals. Once you know your goals, it is pretty straightforward to go about building a solution that meets the goals. Maybe not straightforward, but at least well understood. OK, understood.

Unless you’re already great at delivering software product success, regardless of how you feel about what it takes to get from goals to delivered results, I’m sure that you find the process of defining the goals in the first place to be much harder.

We wrote about the importance of being goal driven about a year ago, if you need a quick refresher. In short, feature-driven designs are inside-out while goal-driven designs are outside-in.

Defining those goals is what this book is about. Focusing on the intent of your software, from the perspective of stakeholders, in order to create software that meets the intent. This couldn’t have come at a better time for me (a week earlier would have been better, but I’m not complaining). We are working on a project that is in the early stages of definition, where a key element is understanding the goals of the project.

Here’s a quick list of the chapter titles for the book.

1. Introducing Outside-In Development
2. Understanding Your Stakeholders
3. Understanding Organizational Context
4. Making Products Consumable
5. Aligning With Stakeholder Goals
6. Defining Success in Your Stakeholder’s Terms
7. Becoming an Outside-In Developer

First Impressions

After reading and skimming the first 50 pages, I’m positively surprised by the ease of reading this book. The concepts are insightful, but the language is very straightforward and practical. As an example, the authors recognize that there are many stakeholders in a project, and break them down into some different groups – who have different needs, and who must be engaged differently.

• Principals – the business sponsors for a product or project. These folks have business goals they are trying to achieve. Your mission is to understand those goals. You also need to recognize that they may be moving targets, and be prepared to adapt to those changes. And we need to understand why they want what they want.
• End Users – the people who ultimately interact with the software. The best software development processes are focused on satisfying the end users. And a lot of authors are out there teaching us how to do that, although none perhaps as visibly as Alan Cooper.
• Partners – people who are neither principals nor end users. These are the folks who don’t directly benefit from your product, don’t use it directly, and didn’t help create it. But they are responsible for helping your product live, thrive, and interact with other products. Think IT people, keeping your system running, and keeping other systems talking to it.
• Insiders – the people who define the product. Your (internal) team. Not only product managers and developers, but business folks, marketers, testers, support staff, finance, etc. The people creating a product influence what ends up being created. And they are stakeholders in a narrow scope – they are affected by the creation and ongoing support of your product.

Carl and John focus on these stakeholders, in this order of priority. Good stuff. There are elements that pop up repeatedly that make the text also read practically, realistically, and credibly. Things like an aside about how principals often don’t want to, or can’t articulate crisp goals. How project sponsors are often unavailable (and how to find proxies for the sponsors, and why to take those inputs with a grain of salt).

More To Come

We’ll write more about the book as we get a chance to read through it, and conveniently apply some of the ideas that the authors present us – and provide feedback. I’ve got a bookmark in the section on organizational context right now, and an idea of how to draw and understand something for my current project, based on one of the concepts. I can’t wait to start it in the morning.

So, go buy the book, and bump it up to number 1. [Handy link below in the Recommended Reading box]