Oh boy... "But I do think this is revolutionary. The typical processes people use for understanding a novel business domain take weeks to months." You must be

Oh boy... "But I do think this is revolutionary. The typical processes people use for understanding a novel business domain take weeks to months." You must be aware that there is a large group of people who have largely solved the problem of learning about a domain when client is in the room. It includes Business Analysts, System Analysts, some portion of people who call themselves Solution Architects, some portion of people who call themselves [software] consultants, and probably other roles, too. There is nothing significantly new to ES. It's a specific method to run a workshop, with a client, live. It's one of many, many well known methods used in IT design/analysis. Not under this name though. It's the same as half of Agile Industrial Complex (to quote on of Agile Manifesto's authors) -- people take a good technique and give it a name to market themselves or to promote the technique in the industry. Don't fall for it. "Traditional processes for understanding the domain also tend to focus on nouns." I don't know where you get this from. What processes do you mean specifically? If you look at BABOK (Business Analyst body of knowledge, a good reference point), you will notice a huge section of _dozens_ of tools used to map and understand a domain and then to model a system for that domain... ES is just one item out of many, many methods. Many of those methods have nothing to do with nouns, they are far more generic. Sorry about the rant, but I was just sharing the same thoughts with a colleague who's learning some basic aspects of business/system analysis, so here goes... The actual, real problems with running _any_ kind of joint work on requirements with clients are the REAL challenge of software dev teams in most models, and here's just a taste of what they can be: 1) client won't come to see us. Yes, seriously. 2) client will agree to a VC, but VC quality is so poor we have to go to them 3) we can go to the client, but we will never get 2-3 key stakeholders in the same room before project deadline. So we must do separate workshops, which complicates things. 4) Getting a team of people to another country for several workshops gets expensive fast. 5) Some members of the team don't want to or can't go And now for the actual work... 6) Facilitation of a workshop such as this is generally a difficult job, one needs specialized skills to make it effective. ES proposes a format, which can be helpful, but to get value from a workshop you need good facilitators on the team AND a format, not just a good format. If you can have only one, pay for a facilitator, and let him pick any format, it's generally more useful. Formats are easy to get, and won't cover all the needs of a particular client-team relationship anyway. 7) Facilitation of a workshop is generally far beyond what a typical 25-30 year old software developer can handle given their typical focus (this specifically targets the myth spread by one optimistic ES promoter in my country who tells developers "just do ES workshop!" but fails to recognize the high level of soft skills required to make it effective, esp. with clients who don't have much time). 8) wrong people from the client have come, but you only realize it halfway through the workshop. Time wasted, potential misinformation spread 9) time required to collect all the necessary information this way is larger than total time you have to deliver something to the client to prove to them you are a good supplier of software. So you need results much sooner than this before they even let you work with them. And finally... 10) People take time to ingest and process information. Lots of new information + many people = long time. It's not 1 day and we're done. Summary: Just hire an analyst and your team will thank you. If your team is already good enough in terms of facilitation skills to run Event Storming, you don't need Event Storming.