Requirements existed only in people's heads
No single source of truth for business, functional or non-functional requirements — so scope, effort and risk could not be estimated.
Case study · Discovery & prototyping
I&B Monitoring: product prototyping that turned a monitoring idea into a fundable MVP
Six months of business analysis, solution architecture and UI prototyping gave a Kyiv-based monitoring vendor a defined product vision, a prioritised story map and approved interactive prototypes — everything needed to start building an MVP for mid-sized organisations without guessing.
- 4
- Specialists on the team
- 6 mo
- Idea to approved prototype
- 50+
- Client's end customers in scope
- 4
- Roadmap scenarios delivered
About the client
Monitoring built for the companies enterprise tools ignore
I&B Monitoring is a technology company set up to give medium-sized organisations an efficient, affordable way to monitor their infrastructure — the segment that finds enterprise observability platforms too heavy to run and too expensive to justify, and open-source stacks too demanding to maintain.
The founding team knew the operational problem in depth and had a strong technical core. What they needed was the product layer: an agreed scope for a first release, an architecture that would not have to be thrown away, and an interface their own customers could understand in the first five minutes.
- Industry
- Technology · Data & monitoring
- Location
- Kyiv, Ukraine
- Partnership period
- 2023–2024 · 6 months
- Engagement
- Discovery & design pod
Services
Expertise delivered
Toolchain
Business challenge
A strong idea, no agreed product — and a build that could not afford a false start
Everything the client knew about monitoring lived in conversations, spreadsheets and half-written documents. Before a single sprint could be planned, that had to become one prioritised, architecturally sound scope.
Everything felt equally important
Without a prioritisation model, an MVP would have grown into a full platform and missed its funding and market window.
Two systems, one product
Orchestration and analytics needed to be separated cleanly — a Control Plane for communication, resources and authentication, and an application for analysis and visualisation.
Mid-market usability bar
Mid-sized organisations rarely have a dedicated observability engineer. The interface had to be readable by a generalist IT lead on day one.
Architecture decisions with a long shadow
Data model and stack choices made for an MVP would define the ceiling for scale later, so they could not be deferred to development.
Unclear division of labour
The client had in-house engineering strength; who builds what, and in which order, had to be an explicit decision rather than a habit.
What the client wanted
Five outcomes agreed before the first workshop
The objectives were written down and used as the acceptance criteria for the engagement itself — the same discipline we then applied to the product.
Objective in one line
Define the product vision, gather detailed requirements, and design an intuitive user interface for the MVP.
- 01
Gather and document business, functional and non-functional requirements for the MVP.
- 02
Design and iterate interactive UI prototypes that make the product’s functionality and user experience visible.
- 03
Define the technical architecture and select a detailed tech stack that supports those requirements.
- 04
Create a visual map of product functionality to clarify requirements and set feature priorities.
- 05
Develop collaboration scenarios between the two teams for building the Control Plane and the monitoring application.
Project phases & workflow
Three phases, each with a dated deliverable
No phase closed on a status update. Each one ended with an artefact the client could review, approve and reuse in development.
Requirements identification and documentation
Workshops, stakeholder interviews and document analysis turned tacit knowledge into a written scope: business goals, functional and non-functional requirements, the key business processes behind them, and the solution architecture that would carry them.
What we delivered
- Requirements document: business, functional and non-functional scope plus solution architecture
- Story map showing product functionality with agreed priorities
- Interaction diagrams for the main product flows
User interface prototyping
The requirements became clickable. Interactive prototypes covered the core monitoring journeys — onboarding a resource, reading its state, reacting to an incident — so stakeholders could critique real navigation instead of describing it.
What we delivered
- Approved interactive prototypes for the product's core functions and navigation
- Screen inventory scoped to the first development sprints
- Feedback rounds logged against the requirements document
Long-term vision and strategic alignment
We closed by mapping four realistic ways the two teams could build the MVP together, so the immediate plan and the three-year product ambition pointed in the same direction — and the client could choose on cost, speed and control.
What we delivered
- Four collaboration scenarios for the Control Plane — communication, resource management, authentication
- Matching scenarios for the I&B Monitoring application — data analysis and visualisation
- Trade-off summary per scenario: team shape, timeline and ownership
Approaches we used
Four techniques, applied in a fixed order
Client interviews
Separate conversations with each stakeholder group, so competing views surfaced early rather than during sprint review.
Document analysis
A review of existing material — processes, draft architecture, prior requirements — to reuse what was already sound.
Story mapping
One visual map of functionality that made prioritisation a shared decision and drew the MVP line explicitly.
Workshops
Joint sessions to resolve open questions, brainstorm options and re-align priorities as the picture sharpened.
Value delivered
What I&B Monitoring owned at the end of six months
A foundational requirements document and prototype
The basis for every later MVP development stage — written once, referenced continuously.
Operational and strategic needs aligned
A product vision that supports data-driven decision-making for mid-market customers, not just a feature list.
Technical architecture and tech stack decided
Chosen against the documented requirements, with the Control Plane and the analytics application separated by design.
Roadmap scenarios to start building
Four costed collaboration models, so the go-decision was a choice between known options.
The strongest signal was speed of agreement: by the end of phase two, prototype reviews were being closed in a single round, because everyone was arguing against the same documented requirement rather than their own memory of a meeting.
Collaboration and key roles
A four-person pod, plus the client's decision-makers in the room
Project leader
Coordination, scheduling and prioritisation across both teams.
Business analyst
Gathers, analyses and documents requirements; owns the story map.
Solution architect
Technical architecture, stack selection and strategic planning input.
UI designer
Prototypes that carry the functional and interaction requirements.
Business representatives
Client-side: approve prototypes, give feedback, hold the market view.
What happens next
From approved prototype to MVP development
The next phase builds the MVP against the documented requirements and approved prototypes: core functionality first, then iterative releases that improve usability, add integrations and widen the feature set as mid-market demand grows.
FAQ
Questions we get about discovery and prototyping
How long does a product prototyping and MVP discovery phase take?
For I&B Monitoring, six months end to end: two months of requirements work, one to one and a half months of interactive prototyping, and two weeks of roadmap alignment.
What do you get at the end of it?
A requirements document, a prioritised story map, the solution architecture and tech stack, interaction diagrams, and approved interactive UI prototypes.
How large is the team?
Four Bintime specialists here — project leader, business analyst, solution architect, UI designer — working directly with the client’s business representatives.
Can Bintime build the MVP afterwards?
Yes. Discovery closed with four collaboration scenarios, from a fully Bintime-delivered MVP to a mixed team alongside the client’s own engineers.
Start a conversation
Have an idea that needs a scope before it needs a sprint?
Tell us where your product is today. We will come back with what a discovery and prototyping phase would look like for it — duration, team, and the artefacts you would own at the end.
- Reply within 24 hours from someone who can scope it
- Sample requirements document and story map on request
- NDA signed before any detail is shared
Thank you
We will get back to you within 24 hours with a proposed discovery scope.