When the operating context changes the product
An education software product needed to represent how schools organized their work. Existing designs and work breakdowns needed to be revisited against the actual workflows and business rules.
The discovery covered work being managed through spreadsheets, email and documents, including scheduling, grading and reporting. Those activities helped make the questions behind the software model more concrete.
My contribution
I contributed to domain discovery and product-model redesign, working with business and technical colleagues. This included clarifying questions and assumptions, documenting business rules and connecting them to a revised model.
My work focused on discovery and the product model, alongside the team's engineering work.
Connect the organization to the product choices
I redesigned a multi-tenant education SaaS product model connecting organizational structures to role-based access, white-label configuration, pricing and usage metering.
In practical terms, those choices concerned how organizations and users would be represented, which actions different roles could take, what could be configured for different organizations, and how pricing could relate to use.
| Model choice | Operating question | Connected definition |
|---|---|---|
| Organization | Which school or organization does this work belong to? | Tenant structure |
| Role | Which actions may this person take? | Permissions |
| Configuration | What varies between organizations? | White-label settings |
| Commercial use | What does the pricing model count? | Pricing and usage metering |
The revised data model was connected to requirements and work estimates, giving the development team a defined scope for implementation.
The handoff and its limits
The result was a redesigned product model and a handoff for implementation. Production use of the full design and its business impact remain unconfirmed.
A question to take into your own project
Before treating a design as ready to build, ask whether it represents the people, organizations and rules the product must support. A more detailed plan can still depend on an assumption that needs another look.
Consider the questions for an idea or first release
Read the reasoning about shared investment
Use the guide before committing to software or AI
Keep a waiting decision moving
Making the handoff reviewable
The useful connection was between the organizational model and the decisions built on top of it. Roles, configurable behavior and usage-based pricing cannot be treated as separate screen features if they describe the same organization. I connected those questions to the revised model and the requirements handed to the development team.
