In today’s fast-paced business environment, the synergy between non-technical (product) and technical teams is more crucial than ever. Yet, these teams often find themselves speaking different languages, leading to misunderstandings and project delays. How can organizations bridge this gap to foster better communication and collaboration?

One effective approach is the use of custom modeling languages that incorporate concepts understood by both parties. By focusing on shared language elements and tracing ideas from rough concepts to detailed designs, teams can work more cohesively. This article explores how custom modeling languages centered around system objects, structure, and behavior can unite product and technical teams, using an e-commerce system as an example.

The Power of Custom Modeling Languages

Custom modeling languages serve as a common platform where both non-technical and technical teams can articulate and visualize system requirements and designs. These languages use intersecting concepts that are familiar to all stakeholders, facilitating clearer communication and reducing the risk of misunderstandings.

Key Concepts:

• System Objects: Fundamental elements that represent real-world entities within the system.
• Structure: How system objects are organized, represented by product and solution blocks.
• Behavior: How system objects act and interact, depicted through product and solution use cases.

Intersecting Language Concepts

System Objects with Structure and Behavior

At the core of any system are the system objects, which possess both structure and behavior. By defining these objects, teams create a foundation that both sides understand.

• Structure: Represents the static aspects—how components are organized.
• Behavior: Represents the dynamic aspects—how components interact over time.

Structure: Product and Solution Blocks

• Product Blocks: High-level components that define what the system should do from a business perspective. For example, in an e-commerce system, this could be the “Shopping Cart” or “Product Catalog.”
• Solution Blocks: Technical components that detail how the system will achieve the product requirements. This includes databases, servers, and application layers.

Behavior: Product and Solution Use Cases

• Product Use Cases: Scenarios that describe user interactions with the system, such as “Place an Order” or “Search for a Product.”
• Solution Use Cases: Technical workflows that support product use cases, like “Process Payment Transaction” or “Update Inventory Database.”

Product Level Modeling in an E-Commerce System

At the product level, modeling focuses on capturing the business requirements and user interactions.

Example: Customer Journey

1. Browse Products: The customer explores the product catalog.
2. Add to Cart: The customer selects items to purchase.
3. Checkout: The customer provides payment and shipping information.
4. Order Confirmation: The system confirms the order and provides tracking details.

By mapping out these product use cases, non-technical teams can convey their needs clearly to technical teams.

Solution Level Modeling

At the solution level, the modeling becomes more detailed, incorporating components, classes, and methods that technical teams use to build the system.

Example: Processing an Order

1. Order Component: Manages order data and interactions.
   • Classes: Order, OrderItem, PaymentDetails
   • Methods: validateOrder(), processPayment(), updateInventory()
2. User Component: Handles user authentication and profiles.
   • Classes: User, Address, Authentication
   • Methods: login(), logout(), updateProfile()

By aligning these solution blocks with the product blocks, technical teams can ensure they are meeting the business requirements.

Tracing Ideas from Concept to Design

The intersecting concepts allow for seamless tracing of requirements from initial ideas to detailed technical designs.

• From Product Use Cases to Solution Use Cases: Each product scenario is linked to technical workflows.
• From Product Blocks to Solution Components: Business components are mapped to their technical counterparts.
• From System Objects to Classes and Methods: Objects defined at the product level are translated into classes and methods in the codebase.

This traceability ensures that both teams are aligned throughout the project lifecycle.

Applying the Toolkit Strategies

To further enhance collaboration, organizations can implement several strategies:

Bridge Gaps

Use the shared modeling language to facilitate communication. Regular meetings to discuss models can help both teams stay aligned.

Discussion with business stakeholders should be done based on the product modeling language while discussion with technical stakeholders should be done based on the solution modeling language. Intersecting discussions may focus on the transition from product to solution modeling to ensure that the business requirements are translated into technical requirements.

Empathize More

Encourage team members to understand each other’s perspectives. Non-technical staff can attend technical walkthroughs, while technical staff can participate in business requirement sessions.

Define Roles

Clearly outline who is responsible for each part of the modeling and solution process. This clarity prevents overlaps and confusion.

E. g. a product owner is responsible for the product aspects of the system, while a solution owner is responsible for the solution modeling. That means that the former is also responsible for product use cases and product blocks, while the latter is also responsible for solution use cases and solution blocks.

Foster Respect

Acknowledge the expertise each team brings. Celebrate successes jointly to build mutual respect.

Create Liaisons

Appoint team members who are fluent in both product and technical aspects. These liaisons can translate and mediate between teams.

Continuous Learning

Promote ongoing education. Workshops and cross-training sessions can help team members appreciate the challenges and workflows of their counterparts.

Conclusion

Bridging the gap between non-technical and technical teams is not just about better communication — it’s about creating a cohesive environment where ideas flow seamlessly from concept to implementation. Custom modeling languages that use shared concepts like system objects, structure, and behavior can play a pivotal role in this process.

By applying these principles and fostering a culture of empathy and continuous learning, organizations can enhance collaboration, drive innovation, and adapt more quickly to market demands. The e-commerce example illustrates how these concepts can be practically applied, but the approach is versatile enough to benefit projects across various industries.

Future Enhancements and Sophistication

While the toolkit provides a solid foundation for bridging product and technical teams, there’s room for further sophistication.

At the product level, more detailed requirements modeling could be introduced, incorporating user stories, acceptance criteria, and business rules. Similarly, at the solution level, technical modeling could be expanded to include architectural patterns, data models, and API specifications.

Underneath the solution level, additional layers of abstraction could be added, such as infrastructure modeling for cloud deployments or performance modeling for optimization.

Moreover, extending the language concepts to include roles and interactions would provide a richer context for system behavior. Roles could represent different user types or system actors, while interactions could model the complex relationships between system components.

These enhancements would create an even more comprehensive toolkit, enabling teams to model and communicate increasingly complex systems with greater precision and clarity.

Final Annotations on how to use AI to Answer Questions

My personal goal for this article was to answer a call for a LinkedIn advice question (https://www.linkedin.com/advice/0/what-do-you-technical-non-technical-teams-clash-obaif) in no time by involving AI. It turned out not to be that easy this time. Most of the time was spent checking the result and tweaking the prompt half a dozen times to improve it. The reason seems to be in the complexity of the request and the need to adapt to the limitations of the AI by playing with two abstraction levels and also taking into account my personal experience in various projects. The situation should improve with increasing personal knowledge base accessible by the AI.

Used approach

• Copy LinkedIn article into Cursor AI (https://www.cursor.com/) as separate markdown file (can be improved avoiding copying every single section)
• Create a prompt in Cursor AI in yet another file
• Use chat in Cursor AI (well, half a dozen iterations) and save result in yet another markdown file
• Manually improve the result with selective changes directly in Cursor AI (select text, Ctrl-K, command).

A beautiful side effect is that the sections are answered in a connected way and not separated from each other. I hope this can be helpful for you as well. Thank you for reading and forgive me not having spent more time on a perfectly generated image.