The one thing that unifies all software developers is at some point in our lives is when we created some software that did something cool, a light went on, and we got hooked. However, building software for ourselves is very different from building software for someone else. We have to be motivated to work collaboratively to set up the right environment and make the magic happen.

No matter what type of software product we're building, there is always an element of uncertainty in what the final shape of that outcome will be. And so, when we work with our customer to bring their idea to life, we work on the premise that the concept itself is likely to have holes in it and we will have to work to fill in the gaps.

We know as we begin to build out potential solutions that we will discover much new information and we will need to learn at a rapid rate. As we discussed back in Chapter 11, Improving Our Team Dynamics to Increase Our Agility, there has been a distinct shift in where the knowledge resides in an organization and as knowledge workers we operate at the intersection of three streams of information:

1. The application/problem domain—the business
2. The solution domain—technology
3. How we deliver, sometimes referred to as the process domain

At this confluence, we act as trusted advisors to guide our customer to get a good result. In my experience, this creates two opportunities:

1. We can create a direct bridge between our customer's world (the application/problem domain) and our world (the technology/solution domain) which helps us both begin to understand how we might build something truly useful. 
2. We can set up an environment for discovery, where we need to learn rapidly and are prepared to take a degree of risk. Here we have to make a working agreement with our customer that we will work with them to uncover what we need to know.

So, we won't start with all our requirements nailed down. As we discussed earlier in this book in Chapter 1, The Software Industry and the Agile Manifesto, it's often not plausible to do so. The more novel the idea, either regarding its application or its solution, the higher the uncertainty will be. Especially if our customer is trying to create a point of difference—something that differentiates them from their competitors in the market.

Fortunately, if we use adaptive planning in quick cycles to build increments of working software, we will quickly discover what will and won't work. This will also work to reduce the risk rapidly for both us and our customer. Plus, using an adaptive strategy means our customer should experience a higher degree of control in the direction we take, creating a win-win.

This, in my mind, is what leads us to take a more entrepreneurial mindset to our work. We accept that we can't know everything up front, so we will have to work with a degree of uncertainty and risk. To get comfortable working with risk, our methods need to seek it and constantly try to reduce it.

An entrepreneurial culture is important because, for the adaptive approach to software development to work, we need to set up the environment in such a way that we can learn rapidly. Creating feedback loops is what tells us whether our idea is working or not.

It's only usually after experiencing this approach that our customer will understand and trust it. For them to enter our world, they will need to take a leap of faith. They are used to a world that tells them how much something is going to cost up front. Hopefully, we will be able to show them that adaptive approaches to building software products are more likely to result in something that they will find useful and may well delight them.

And while we might not be taking the financial risk ourselves, we should work with our customer responsibly, as if their money was our money. Therefore, we need to work closely with our customer for two reasons:

• So that they can learn about our world as much as we learn about theirs.
• Closer working will achieve a much better outcome.

What we learn pretty fast is that we need to be pragmatic and focused, getting the balance right between learning enough about the domain so that we can solve the problem with just the right technology, and then delivering it in a way that is going to get feedback early and often so that we can adjust our approach if necessary.

So, being entrepreneurial isn't necessarily about starting a new business, it's about the mindset that we need to have if we're continually investing energy into new ideas. This is something that we're very familiar with in the tech industry. The mindset requires people who are curious, collaborative, have humility, are adaptable, and can spot new opportunities.