Chapter 3. Conceptualization

“An architect is the drawer of dreams.”

Grace McGarvie

“It is essential to an architect to know how to see: I mean, to see in such a way that the vision is not overpowered by rational analysis.”

Luis Barragán

“The great thing about being an architect is you can walk into your dreams.”

Harold E. Wagoner

“I claim that is where architecture starts, with the concept.”

Louis Kahn

Have you ever been listening to someone talk, and the ideas you hear begin coalescing into notions? These notions don’t have names yet, but they are real, though a bit cloudy. As the conversation continues, these notions continue to evolve into ever more solid ideas. Eventually these ideas take on personalities and names of their own: you can draw them, name them, relate to them, and talk about them as if they were sitting right next to you. This process is known as conceptualization, ideation, or sometimes the fuzzy front end.

In the world of software development, the architect is typically one of the chief links between the business world and technology. Your ability to hear what the business wants, translate it into a high-level concept, and align it with the strategic needs of the business is a vital role.

This chapter unveils one of the essential skills needed by a software architect: the ability to conceptualize a client’s or customer’s notion into something implementable through ideation.

Ideation

Ideation is a customer-centric solutions approach where the focus is finding new ways of solving customer problems. In a business setting, the focus is not simply solving new customer problems but adding value in a way that will ultimately drive revenue, reduce costs, or gain/maintain strategic advantage (see Figure 3.1).

Figure 3.1. Ideation is customer centric; contemplate a variety of alternatives to meet the customer’s needs.

Getting Involved Early

Usually long before you begin ideating with someone, you begin forming a partnership.

Ideation is risky; you are exposing your dreams, you are vulnerable. If your partners don’t like it, the idea may die before it gets a chance to take wings and fly.

Ideation is fundamentally founded on the notion of trust: Will you help embellish the idea? Will you try to kill the idea (it’s not yours)? Will you try to steal the idea (use it as your own as a vehicle for your own success)? Trust is an essential quality to establish in a partnership for the purpose of ideation.

Sometimes you have the time to slowly form a connection with the person or group. Other times you are thrust into a situation where trust may not yet be present. If it is not, you will need to start working on building it immediately.

Learning your role in the partnership is essential:

• Are you the leader?

• Is this your idea?

• Are you there to help crystallize the ideas?

• Are you there as more of a fly on the wall? (It’s okay to listen, but you may not have earned speaking rights yet. It may be okay to ask questions in these situations, but wait and feel the situation out; it’s not always clear.)

Over time, you may establish enough trust that your partners or customers will share not only their current ideas, but their ideas about the future, the big ones that can shape the future business and have a meaningful impact on others.

Typically, a place in the partnership is earned through hard work, socialization, and your ability to assimilate into the group.

If you are fortunate enough to win over their trust and demonstrate value early in the ideation process, your customers will eventually begin inviting you to the table for their earliest conversations and treat you like a full partner.

For more information on partnerships, see Chapter 1, “Partnership.”

Conceptualization: Bringing Ideas to Life

Conceptualization and ideation lead to some of the most exciting times in the product development life cycle:

• Your understanding of what the customer is seeking grows dramatically.

• The range of possible solutions explodes.

• How existing ideas and new ideas can be synthesized causes revolutionary thinking about your products.

This process of bringing concepts to life is one of the foundational elements of software architecture (see Figure 3.2). The conceptualization life cycle is rooted in seeking the essential.

Figure 3.2. Concept life cycle

Concept Formation

Concepts are formulated and reformulated many, many times during the product development life cycle. There are several key elements of building a foundation for these product concepts. These include forming a common language, understanding the context of the user, and developing visualizations of the concepts.

What Language Are They Speaking?

After you have begun working with a new group, customer, or partner, you begin to hear words being repeated; they have a distinct usage, pronunciation, and context. Your understanding of the subtleties of these words and their meaning is the beginning of your acceptance into the new tribe. This language enables your new tribe to communicate effectively, quickly, and precisely.

For me, capturing this language visually is the first cognitive form of understanding with the tribe. Until I am able to converse in their language and understand the meaning and interactions between the words they are using, I am not really part of the conversations that are taking place. It’s like being dropped off in a foreign country: at first you are struggling to learn not just the basics, but the essentials—the equivalent of “Where is the bathroom?” “Where are the restaurants?” “Where are the hotels?”

The visual form this takes is usually a domain model. At first, I am simply trying to relate the words to something I already know and understand. If I can make the leap—for example, “This is just like a manufacturing process, this is just like a compiler,” or some other process or system I am familiar with—I can establish a bridge to what is being conceived and can begin to have a high-level understanding of what is really being talked about.

Until you begin to understand these language nuances, you are doomed to poor decision making and forming assumptions that are simply wrong.

These are your future budget busters—the “Oh, I remember talking about that; you meant . . . ,” and the reply, “I never said that; I said. . . .” The realization that you did in fact talk to each other but no real conversation occurred begins to emerge, and your opportunities for a smooth-sailing project diminish.

At this early point, I am just trying to understand the main concepts and the meaning of the words used:

• What is the “big picture”?

• Who are the stakeholders?

• What are the use cases?

• What are the key nouns?

• What are the key verbs?

• How do they relate (associate) to one another?

• What is their cardinality?

• Is there a hierarchical (“is a kind of”) relationship and if so, what is it? For example, this a vehicle; a Ford is a kind of vehicle; a vehicle has doors, sometimes two doors, sometimes four doors, . . .

• Are there any natural process flows that occur?

Although these initial models may be partially wrong, that’s okay; they begin to give you a foundation for understanding what is being said around you. These models typically take the form of diagrams (simple boxes, nouns and connecting lines, verbs; see Figure 3.3).

Figure 3.3. Domain models and a glossary of terms are effective tools for capturing the language of the customer.

“Models are incredibly sticky—because they help people understand the world.”

Olivia Mitchell

What Problem Is Being Discussed?

As you begin diving into business problems that need to be solved, whether for internal or external customers, you need to become familiar with these issues:

• What is the set of problems to be solved? Knowing and understanding the purpose of what you are doing will bring clarity to the product concept.

• What are common practices for solving the problem today? Gaining a sense of how people solve a problem today can begin to suggest how the solution might be automated, what aspects may not be able to be addressed by a system, and what areas can be improved.

• What are the results the customers are hoping for? What is the value add? Why would customers want to spend money on this? How does it make their life better? Ideas are plentiful, but adding real value is the key to a successful product concept.

• What are the possible new ways of solving the problem? Coming in from the outside can be a good thing. It can enable you to think about how you would solve the problem from a fresh perspective and enable new, innovative ways to delight the customer.

• Is there a process to solving the problem? If so, can it be described? Some things are not simple tasks but require a sequence of steps. Capturing these steps can give you a place to start from and help you see where improvements or wholesale changes can be made.

• How is the customer going to earn money or save money?

• What is the value proposition of the solution for the customer?

• To whom will the end solution be targeted? Do the intended end users really think they have a problem?

Answering these questions with a domain model can help place the customer’s problem in an understandable context and help drive the needed capabilities within the system.

When Arriving Late to the Ideation Party, Be Cautious about Committing

Sometimes when you enter a conversation, everyone else is miles and miles in front of you. They have worked together for years, they are “experts” in the area, and you are the new person on the block. You don’t know a pothole from a pile of gold. The solution is already at hand and they are willing to commit.

Be cautious about what you commit to.

If you don’t understand the problem and its context (even when everyone else does) and you are the new architect being thrown into the mix, let it be known that you are responsible for this decision and you will be held accountable—you are the architect. Do you know what you are committing to? If the answer is no, stop the train; now is the time for you to understand

• The domain

• The problem to be solved

• The context of the problem

• Alternative solutions

• Where the business is trying to go

One of the special rights you have as an architect is to say no. Be prepared to defend yourself and justify your answer, but you do have the ability to stop the train (see Figure 3.4).

Figure 3.4. Learn to say no and stop the train if you are not confident you can reach the destination.

Saying no is a very effective tool for putting things on pause and allowing further investigation or justification to occur.

• Would you at this very instant feel comfortable asking for money for this solution from an executive? If not, say no.

• Would you feel comfortable selling this solution to an investor or client? If not, say no.

• Are you reasonably confident that you have vetted this solution? If not, say no.

“Yes means nothing if you can’t say no.”

Peter Block

Remember, your reputation, your relationships, and your future viability within the organization are at stake.

Bottom line is that architects need to get as many of the facts as possible and make an informed decision. It takes years and much success to build a great reputation, and it can crumble in an instant if a bad decision is made.

The goal is not to say no permanently, but long enough that reasonable options can be presented.

Taking the time to document the facts, assumptions, and risks that were known at the time of a decision can help calm the firestorm that may ensue later if things do not work out and executives are seeking an explanation.

What Does This Concept Look Like?

As you have been listening and engaging in the conversations about the problems being faced or the new opportunities that exist, you are likely to have started forming visual models of what the major components of a solution may look like (not detailed visualizations, but rough sketches—high-level boxes that begin encapsulating portions of the solution). These may be captured in a notebook, on a whiteboard, in an electronic solution (such as Visio or some other drawing tool)—it doesn’t matter. The key is to begin capturing a variety of ideas about how the problem might be approached. There are no right or wrong answers; you just want to begin playing around with the problem. Start to discover

• Where the real boundaries exist

• What the real requirements might be

• Who the real customers are

• What constraints exist

• What the main components of a solution are

You are working to discover as much about the problem and/or opportunity as you possibly can. Ideally, becoming involved in this process as early as possible is advantageous; doing so gives you the opportunity to

• Influence the solutions that will be considered

• Give the business a sense of the difficulty of solving the problem

• Give the business a sense of the cost of developing a solution for the problem

• Suggest alternatives that may solve part of the problem—but solve it with little or no cost (the low-hanging fruit)

• Find areas in which to partner with different groups and share the cost of developing a solution

• Find solutions or possible approaches from other domains

• Gain a better sense of where the business wants to go and potentially allow you to find a series of solutions that will get the business to the end state. (This may enable the potential for multiple business cases to incrementally fund the end state and reduce the overall risk.)

“The real voyage of discovery consists not in seeking new landscapes but in having new eyes.”

Marcel Proust

At this stage, developing context diagrams and conceptual diagrams will give you something to talk about as you discuss the problem and possible alternatives. Sometimes having several different diagrams can be helpful to show that this is not a fully baked solution but rather a series of alternatives to compare, contrast, and embellish.

Your ability to get involved at the very outset of ideation can have a dramatic impact on your ability to frame alternative approaches to how to deliver solutions. This context is invaluable later in the project or projects that are derived from this ideation.

Getting involved early fundamentally changes your role from being a solution provider/contractor to being a partner (one who sits at the table and contributes your best and brightest ideas). If you come into the process later, many of the boundaries for the concept have already been established and the willingness to rehash decisions may be limited.

Getting customers involved (finding out what problems they really have, where they will part with money, and how they deal with this problem today) can dramatically improve your ability to understand what products need to be produced and how they need to work.

If and when customers are involved, work hard to be at the table. Normally, businesses are terrified of the Dilbert effect that technologists bring to the conversation.

Early on, be cautious and work toward establishing trust; you need to demonstrate that you can be a good citizen in public before your influence can begin. Hearing a variety of customers react to the proposed concept can have a dramatic impact on its shape, size, and complexity. I have personally seen concepts that were radically more complex than the real needs of customers required.

The continual refinement of a concept with exposure to multiple customers (under NDA, of course, and paid for their time and efforts) can begin bringing clarity and understanding that simply never existed before. There begins to form a simple (nonessential elements removed) and elegant structure to the concept, one that may in the end require only a fraction of the cost to implement.

I have seen a case where the final solution was only 10% of the cost of the initial estimates for implementation due to early customer involvement, and where the solution was far more strategic in nature (it focused on at most a handful of essential things and delivered on them) and had applicability to many different business opportunities.

The key to success is to listen:

• Get the customers to talk.

• Ask questions.

• Record your conversations if the customers are willing to let you.

• Let them follow their own rabbit trails (that is usually where the gold is).

Remember, this is about the customer, not you:

• Let them talk.

• Don’t interrupt.

• Be gracious.

• Be willing to change.

• Invite a variety of customer roles to be involved in the conversation; they usually have a wide range of views and insights into their world that they are happy to share if you give them the chance.

• Listen for legal concerns, human concerns, maintenance elements, and regulatory concerns that you may not have had knowledge of before.

The ideas, comments, and concerns that the customers express may very well be the keys to your delivering a solution that in the future will allow you to stand tall among your competitors.

As you speak to multiple customers, you will begin seeing new threads appear that you never perceived before. Having a small but limited team focus on the concept development can help establish trust and enable real conversations with the team to occur. Usually, allow one new member to travel along; that person’s newness to the concept will help validate it from an outsider’s perspective and ensure that you don’t get so close to the concept that you can’t see the big picture anymore.

Having to explain what you are thinking multiple times can help cement the ideas in your mind and bring clarity to languishing elements of the concept. You may hear comments such as

• “It would make my life so much better if . . .”

• “Really, what I would like is something that could . . .”

If so, capture them; they are the elements of your vision that will make your concept great.

When the opportunity arises to visit with customers, drop everything, even if the invitation to go somewhere occurs at the most inopportune time.

The important decisions usually require you to act immediately, with relatively little information and an unusually high level of distractions all coming to a head at the same time. Learn to listen to the small voice inside and follow your gut. Trusting your instincts and, if possible, consulting with trusted partners are usually good strategies.

Concept Reification

Concept reification is the process of making the product real, focusing on what is essential, assessing what is possible, and establishing essential characteristics of the system.

Minimum Viable Product

“My aim is to omit everything superfluous so that the essential is shown to the best possible advantage.”

Dieter Rams

From an architecture perspective, driving toward a minimum viable product (MVP)—the 20% of the functionality that people will use every day—should be the goal. The full list of features may eventually be required to dominate the market. But when you are trying to get a product out the door quickly and be the first to market, focus on MVP.

The MVP can be a challenge when working with customers or new product development. They typically want it all. By working with them closely, you can usually prioritize and distill the essential product features that need to be delivered first. Accomplishing this distillation will give you the opportunity to focus development resources on what is most important. It will also enable you to begin shipping usable software earlier and to start to generate a revenue stream. Live products have a much better survival rate than prolonged development activities that ship only at the end (they begin to look like money pits to executives).

One indicator that you are on the right track is that the system can be described on one page; it should be conceptually complete, and nothing more can be removed. When diagrammed, if there are any boxes with more than five lines coming out of them, you should evaluate the concept and verify that it is structured properly.

The Need for Experimentation

The area of experimentation is often a challenge for the business and technology in that it is often a nonfunded area of required research. There is often funding for doing the estimates, there is often funding for doing spikes once a project has been funded, but there is not always money to fund simple proofs of concept to determine the feasibility of projects or the lowest-cost approach, the simplest operational approach, or the best technical approach. A lack of funding for these experiments can cause high estimates to be produced in the space where there are many unknowns. This unintentionally causes the business to turn away from opportunities that may well have been great strategic opportunities, but the lack of ideation money causes the business to look elsewhere.

I have found that coming to the business with ideas is not sufficient. Ideas abound, even ideas with a great pitch. The best way to bring ideas forward is to produce simple proofs of concept. Working examples of code that demonstrate an idea—even in very crude, rudimentary forms—tend to have the highest impact and also have the highest likelihood of generating enough interest to get those who hold the financial purse strings to open the checkbooks and pursue formally estimating and authorizing projects (see Figure 3.5).

Figure 3.5. Find ways to experiment and perform proofs of concept—it’s an effective way to build new solutions for the business.

You will need every asset at your disposal to get the business hooked. I like to think of it as “A single proof of concept is worth a thousand estimates.” It will engage the business in ways that almost nothing else will. As the old saying goes, “Seeing is believing.” Without it, you may soon be doomed to an infinite loop of estimating. (My unfortunate personal record is 16 estimates for a project before it moved forward. In the end, the project was very successful, but I hope to never repeat this again: death march estimating.)

Establishing Assumptions Can Help Harmonize the Vision

Working with new product development to begin visualizing the system can bring a tremendous amount of clarity to everyone’s thinking. It will quickly reveal major assumptions being made by new product development, marketing, sales, and technology. This emergence of assumptions is essential to begin harmonizing everyone’s thinking about the product concept.

Establishing Essential Capabilities and Customer Roles

This visualization can also help with the emergence of customer roles within the new system. You will quickly be able to see what capabilities are possible and which are not. The conversations around this will begin the process of concept reification. Thus begins a virtuous cycle that can also include reengaging the end customers to validate the new thinking that has emerged. If they get it immediately, you are on the right track. If they don’t, you need to evaluate what was wrong with the product concept:

• Was it pitched wrong? Different customers have different areas of concern and needs. Knowing a customer’s particular situation and crafting the message to that situation can have a dramatic impact on the customer’s acceptance of what is presented.

• Do the user roles make sense? Each customer may have a slightly different way of managing the problem. Have you captured user roles that easily map onto the way customers manage their business?

• Does the flow of tasks match how the customers work? Each customer may have tasks allocated differently based on specific needs. Is there enough flexibility with how you are approaching the problem to accommodate different needs?

• Are there missing capabilities? As you interact with customers and explain the different aspects of the system, are there areas that they can identify that are missing or don’t really match their needs? If so, dive into these areas in more detail to better understand what their needs are and what would need to be done differently to accommodate them.

• Are the capabilities commingled and need restructuring? The key here is to find out if the granularity of the capabilities is at the level that they need to do their work or at the level at which they allocate work out to individuals. If they don’t align well because they do too much or too little, it could be a barrier for the customer to adopt the system.

• Are nonessential items still present? Are you pursuing any capabilities that the customer simply does not need? If so, try to dig a little further to find out what is different about the situation or how the customer works that makes these capabilities unnecessary.

Based on these outcomes, consider asking customers to explain how your concept does or does not solve their pain points; you might be making the world worse for them. If you hear, “I would never do that,” that is a warning signal that you may be on the wrong track, but at least the customer has identified a potential problem in your product concept.

Let your customers break your preconceived notions. Normally you are looking for validation and a stamp of approval on your thoughts; be open to change.

As you hear new requirements and ideas, there is a tendency to gold-plate the ideas or concepts. Be cautious here. Avoid just looking for requirements to build the cool system you have been desperately hoping to build or use that new technology you just heard about. Focus on improving the concept, not embellishing it.

Reify with Customers

Keeping a regular rhythm of contact with key customers can help validate, provide feedback, and enable new insights into the concepts that are emerging around their needs.

My ideation experience has been that most customers that we have gone out to visit and met face-to-face are more than happy to talk through in detail the work they do and the needs they have. If they are leaders in the area of work they do, they have already spent time thinking about how they can do things better. They are highly engaged, knowing that they are helping to craft the future. As the conversations with the customers and the post-analysis of those conversations continue, the cloudiness of the concepts gives way to clarity. With this clarity, the real product vision and roadmap begin to emerge.

This product navigation through reification helps identify and establish areas of high customer value.

Concept Evolution

The process of developing new products has one constant: change. This continuous change creates the need for continual refinement and evolution of product concepts.

Being a Student of History

At most businesses, many concepts have been around the block more than once. Critical thinking has been done about the problem and for some reason the concept didn’t proceed, because of cost, timing, complexity, or any of a wide variety of reasons.

When you see yourself being drawn into what looks to be a repeat performance, take the time to understand what the previous concepts were. If you are lucky, there may be some documentation or survivors of the previous situation who can relay their war stories about what happened. As you dive into this in more detail:

• Listen carefully for the assumptions, risks, and requirements that drove the previous attempt. These can help give you insights into what may be different about the current proposal.

• Validate what you are hearing against what you have discovered to date. Note what you are finding; it can help when you eventually move into an estimating phase to have a deeper rationale behind what you are saying (and selling).

• Determine if anything has changed and if so, what. Look at changes in the product concept, changes in the market, changes in the customer segmentation, and changes in technology. There are many factors that can influence the feasibility of a product.

• Has technology advanced? Is the technical approach that is under consideration different from what was previously conceived? This may be an opportunity to reduce the cost structure of the project.

• Has your customer base changed or adopted new technologies? Sometimes customer adoption of new technologies can enable different solutions and product concepts to be considered.

• Have your customers tried this solution before? If they have, how did it turn out? Why? Customers can be a great source of knowledge. They have seen and tried out a variety of solutions in the past and likely know where the pitfalls are as well as where they and others have had success.

• Beware of the naysayers. They failed at this, and they might be happier if you fail too. Always filter what you hear. There are usually circumstances that were involved in previous situations that simply may not be in play now.

• Learn, but don’t become infected with negative thinking. If you believe that you can’t do something, you are usually right. You need to be open to what is possible based on your own analysis.

Being knowledgeable about your company’s long-term and near-term history can be a great source of enabling decision making. This is especially true for projects that have failed or succeeded and also for projects that have only seen the light of estimation.

Embracing Multiple Perspectives

As you gather more and more feedback and work toward evolving a concept, consider different approaches for how the system might work, consider ways for how complexity might be reduced if certain assumptions were different, and consider what areas of the concept might have extensibility needs:

• Are you able to capture key aspects of events that occur within a customer’s workflow? Are you able to see ways to automate the work that is being done based on these events? Can they be captured by a system? How common are these workflow events? Do they occur across multiple customers? Can you model these events into state transition diagrams?

• Are you able to recognize common or key customer tasks and their associated flow? The more customers you interact with, the more commonality you will be able to see in how they approach their work, what their typical problems are, and where they are unique.

• Are there critical dependencies between tasks? As you develop product concepts, there are dependencies that become clear with respect to other projects, customer infrastructure, and industry developments. Capture and document these dependencies; they will become essential as you try to move the product concept forward into the estimation and approval stages.

• What risks appear to be emerging? The more you are able to dive into a product concept, the more you are able to begin perceiving risks that are critical for others to be aware of as you move forward into an estimating phase. Capture and document these.

• Are there areas of concern that have been expressed? Try to dive below the surface to find out what the root causes of the concerns are. There may be no problems, or there may be a significant misunderstanding about the product concept being proposed.

• Are new capabilities emerging? If so, name them. Naming things has an amazing ability to bring them to life. Your ability to talk about them, relate them, and refine them increases dramatically.

• Are there patterns to the information you are gathering? If so, name them. Named patterns enable a significant amount of reuse and can act as a great point of leverage within the business. They can also assist with the development of domain-specific languages.

Your ability to synthesize these observations across multiple customers can have a dramatic impact on your ability to produce a strategic solution that has broad customer applicability versus simply a point solution.

For a deeper dive into the area of specific techniques and tools around this area, see the references at the end of this chapter.

Seeking Conceptual Integrity

As you evolve the concept, consider:

• How does this concept align with your other products? In most businesses, there is a suite of products that align with one another. How does your concept fit into this suite? Where does it overlap? Are there capabilities that you can leverage? Are these capabilities built in a way that can be leveraged? Are there areas of integration that should be considered? If the capabilities will be delivered in the near future, can you rely on the other product areas to deliver? If they miss, they may significantly impact your budget if they don’t deliver or deliver in a way that doesn’t meet your needs.

• How does this concept align with the customer base you are targeting? You need to understand how the concept applies to the various market segments and what sets of capabilities overlap and which ones are unique. It will help you understand what is absolutely critical to deliver from a business perspective as development priorities change.

• Can you describe the concept in under two minutes? Always be prepared to deliver an elevator speech. You need to have the core message down cold. You need to be prepared so that if you run into a senior executive you can nail the message of what the concept you are working on is, how it will help the customer, and how it will make the company money.

• Is the concept clear and concise? Do people get what you are saying quickly? If customers don’t quickly grasp what you are proposing, your concept is most likely wrong or you are presenting it wrong. The customer is always right. You need to seriously look into what is missing or needs adjusting.

• Have the essential domain relationships been established? If you can identify key relationships within a domain model, it is likely that there is a natural way that certain capabilities need to function based on the relationships and their cardinality with one another. If you miss these, there will likely be natural impedances within your system that will make it feel unnatural to your end users.

• What are the two or three things that everything else revolves around? Get these areas right. Normally for most products there are a couple of key areas that are absolute must-have capabilities. Find out what these are and what makes them so essential. These are going to be the foundation upon which everything else is built.

• Are there similar concepts or patterns in other industries? Often there are similar capabilities in other industries that you may be able to leverage directly, leverage from a design perspective, or possibly leverage from an approach perspective. Be on the lookout for new and innovative approaches as you look for solutions.

• Can the concept be described on one page? If your concept cannot be distilled down to a single page as an executive overview, you need to take the time to work on the clarity of the concept. At this point, the concept needs to be clear, concise, and quickly understood by someone who is familiar with the area.

The goal is to sync the conceptual integrity of your product concept with the needs of the customer as well as with the needs of the company. The more synergies that can be applied, the more support you are likely to receive within your organization.

Recognizing Adjacent Opportunities

As you go through multiple cycles of product conceptualization, you often begin to hear and see use cases and different customer roles that don’t cleanly align with one another. There is clearly something different about what they are doing and the goals they are trying to achieve. The customers may not have recognized these slight variances, but taking the time to distill these subtleties can potentially result in multiple products that share many of the same features but are marketed to different segments based on their differing needs.

Occasionally when you step back and look at the product concept from a more generic capabilities perspective, you are able to begin thinking about other areas where these capabilities could be applied. Sometimes there are adjacent markets that have more potential value than the current area that you are pursuing. For one concept that we were working on developing, the adjacent market opportunity turned out to be ten times larger than the original product concept.

This new market may have completely different performance and scale needs, but the market insights will give you critical information about the architectural needs of the product and likely future directions the business will want to pursue. The key is to be open to change and to be willing to expand your horizons.

Summary

The road to conceptualization begins with

• Ideation with business partnerships

• Getting involved as early as possible in the process

• Concept formulation

• Understanding the language of the customer

• Developing domain models

• Understanding the context of the customer

• Committing cautiously when you are the new kid on the block

• Visualizing the concept

• Concept reification

• Developing a minimum viable product

• Experimenting with prototypes

• Establishing assumptions

• Establishing essential capabilities and customer roles

• Reifying with customers

• Concept evolution

• Being a student of history

• Embracing multiple perspectives

• Recognizing adjacent opportunities

For technically inclined individuals like me who love to whiteboard and work with business partners to learn new problem domains and new challenges, seeking conceptual integrity makes every day exciting.

References

Amabile, Teresa M., John Seely Brown, Martha Craumer, Peter F. Drucker, Constance N. Hadley, Steven J. Kramer, Theodore Levitt, Andrall E. Pearson, Ellen Peebles, and John D. Wolpert. 2003. Harvard Business Review on the Innovative Enterprise. Harvard Business School Press.

Brooks, Frederick P. Jr. 1995. The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (Second Edition). Addison-Wesley.

Christensen, Clayton M., and Michael E. Raynor. 2003. The Innovator’s Solution: Creating and Sustaining Successful Growth. Harvard Business School Press.

Cooper, Robert G. 2001. Winning at New Products: Accelerating the Process from Idea to Launch. Basic Books.

Cornish, Edward. 2004. Futuring: The Exploration of the Future. World Future Society.

De Bono, Edward. 1999. Six Thinking Hats. Back Bay Books.

Gray, Dave. 2010. Gamestorming: A Playbook for Innovators, Rulebreakers, and Changemakers. O’Reilly Media.

Hagadorn, Andrew. 2003. How Breakthroughs Happen: The Surprising Truth about How Companies Innovate. Harvard Business School Press.

Hohmann, Luke. 2006. Innovation Games: Creating Breakthrough Products through Collaborative Play. Addison-Wesley.

Ries, Eric. 2011. The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses. Crown Business.

Sibbet, David. 2010. Visual Meetings: How Graphics, Sticky Notes and Idea Mapping Can Transform Group Productivity. Wiley.

Von Oech, Roger. 2008. A Whack on the Side of the Head: How You Can Be More Creative. Business Plus.