- There may be challenges to overcome
- Consider a different way of thinking about software product development
- Consider some proven techniques as well
- It takes a whole team to succeed
- Understand your stakeholders
- Understand organizational context
- Make your products consumable
- Align with your stakeholders goals
- Define success in your stakeholders terms
- Become an outside-in developer
- The leaders role in outside-in development
- Essential point: You can get started now
This chapter is from the book
This chapter is from the book
This chapter is from the book
Understand organizational context
John was on a roll: six customer presentations in the past two weeks and the clients loved the new features John’s team had architected for the product. Tailorable user interfaces and highly distributed device management were clearly winners.
One more briefing to go before the team closed plans for the new release. Things looked good. The briefing was about to begin.
Thirty-three minutes later, it was clear that the client had no interest in the discussion. Her body language shouted, “This doesn’t interest me!”
John stopped the presentation.
“This material doesn’t seem to resonate with you. That really surprises me since we’ve talked to other clients from firms like yours who were quite interested.”
The customer seemed relieved to be asked and eager to explain:
- “Five years ago we decentralized everything. In spite of the redundant spending, each of our 12 business units wanted the flexibility.
- But a year ago, our business climate changed dramatically. We’re down to four business units and even they are running cross-marketing plays. We can’t afford the current model, so we’re on a big kick to centralize everything.
- In fact, what we want most is a single common interface that can’t be modified, along with a centralized management model. This seems to be the opposite of what you are focused on building.”
What happened here?
Your clients are affected by the structures, cultures, and initiatives of their own organizations. Because your clients will make purchase and deployment decisions that reflect their organizational contexts, and they probably want to use your products to effect further changes, you need to understand these structures.
Once you do, you can more effectively determine what capabilities your products must deliver in order to help your clients achieve their goals.
By factoring out noise due to organizational context issues from the dialogs you have with your stakeholders, you’ll get feedback more efficiently and get to important insights more rapidly.
That really would have helped John’s situation.
Yes, he was able to recover the meeting by explaining that the product had centralized capabilities too. But he needed outside-in development techniques to figure out what to do with the conflicting client goals that were so closely tied to organizational directions.
This is not an isolated case. Your clients are increasingly looking to change their organizations as they seek efficiencies, flexibility, and market differentiation. They will rely on software—perhaps your products—as an enabler of these changes. You need to understand how to deal with these situations effectively for your products to be relevant.
We cover this in depth in Chapter 3, Understanding Organizational Context.