Core Strategy: Strategic Planning and OKR App
How our business analysts defined requirements, MVP priorities and wireframes for a strategy app tracking goals, OKRs, KPIs and projects on dashboards.
- 6 levels linked, from vision down to projects
- 9 product modules specified, from strategy setup to permissions
- 5 focus areas in the MVP, from planning to dashboards
- ~9 months from discovery to MVP release
Project at a glance
- Client
Core Strategy, a US strategy consulting firm building a software product to help its clients turn strategic plans into tracked execution - Solution
The Core Strategy App, a web-based platform connecting vision, strategic priorities, goals, OKRs, KPIs and projects, with interactive dashboards and reporting - Engagement
Business analysis and product definition for a new SaaS product, delivered remotely from Canada - Duration
About 9 months, from discovery to MVP release, followed by a backlog for the next releases - Our role
Lead business analyst, working with the firm's founders and senior consultants, a product owner, a UX designer, a development team and QA - Scope
Business and functional requirements, MVP scoping, user flows, wireframes, use cases, data and hierarchy model, dashboard and report design, test scenarios and QA support
The challenge
What problem was the client trying to solve?
Core Strategy's clients wrote good strategic plans, then lost track of them once day-to-day work took over.
- Plans left in slide decks
Strategic plans lived in slide decks and documents that were rarely opened after the planning workshop. - Goals and work tracked apart
Goals, OKRs, KPIs and projects were tracked in separate spreadsheets and tools, with no link between them. - No line of sight
Leaders could not see which projects supported which goals, or which goals had no work behind them. - Days to prepare each review
Quarterly reviews took days of manual preparation to gather updates from every team. - Risks out of sight
Risks and issues affecting strategic goals were tracked in project tools, out of sight of executives. - Clients drifting between workshops
The consulting firm wanted a product that kept clients engaged with their strategy between workshops and gave consultants a live view of client progress.
Our business analysis approach
How did we approach the engagement?
We designed the product around one idea: every piece of work should trace up to the vision, and every goal should show the work behind it.
- Stakeholder discovery
We interviewed the founders, senior consultants and several of the firm's clients, including executives, strategy leads and department heads. We reviewed the firm's planning methodology, workshop materials and the templates clients were already using. - Strategy hierarchy and data model
We defined the core hierarchy: vision and mission, strategic priorities, goals, objectives with key results, KPIs, and projects with milestones. We set out the relationships, ownership, time periods and progress roll-up rules between each level. - Business and functional requirements
We documented business requirements for the product as a whole, then functional requirements for each module: strategy setup, OKRs, KPIs, projects, risks and issues, SWOT, dashboards, reporting, users and permissions. - Use cases
We wrote use cases for setting and cascading goals, defining OKRs and scoring key results, tracking KPIs against targets and thresholds, linking goals to strengths and opportunities from the SWOT, logging and escalating risks and issues, and running a quarterly review. - MVP scoping
With the founders and product owner we listed all candidate features, scored them on client value, differentiation and effort, and agreed an MVP focused on planning, OKRs, KPIs, projects and dashboards. - User flows and wireframes
We produced user flows and wireframes for the strategy map, goal and OKR setup, check-ins, the project board, the KPI scorecard, the SWOT workspace and the executive dashboard. Wireframes were reviewed with consultants and pilot clients before UI design. - Dashboard and report design
We specified dashboards and reports, including OKR summaries, KPI scorecards, project status by goal, SWOT views and an organization-wide strategic overview. Each one listed its audience, data sources, filters, drill-downs and refresh rules. - Non-functional requirements
We set requirements for multi-tenant data separation, role-based access, audit history, performance and data export. - Testing and QA support
We wrote test scenarios from use cases and acceptance criteria, including roll-up calculations and permission rules. We supported QA through test cycles and helped triage defects with the product owner.
Solution
What did we deliver?
Area
Problem
What was delivered
Strategy map
Plans stuck in slide decks
A visual hierarchy from vision to strategic priorities, goals and objectives, editable in the app
OKRs
Objectives tracked in spreadsheets
OKR setup with owners, time periods, key results, regular check-ins, confidence ratings and scoring
KPI tracking
Metrics separate from goals
KPI scorecards with targets, thresholds and trends, linked to the goals they measure
Project oversight
No link between projects and strategy
Projects and milestones linked to goals, with status, owner and progress rolled up to the goal
Risks and issues
Hidden in project tools
Risk and issue register linked to goals and projects, with severity, owner and escalation
SWOT analysis
Done once in a workshop and forgotten
SWOT workspace where goals can be linked to the strengths and opportunities they build on
Dashboards
Days of manual review preparation
Interactive dashboards with OKR summaries, KPI status, project health and an enterprise-wide strategic view
Reporting
Inconsistent review packs
Standard reports for quarterly reviews and board updates, exportable for sharing
Users and permissions
No control over who sees what
Role-based access for executives, goal owners, contributors and consultants, with separated client data
Governance
How did we manage requirements and quality?
Every requirement could be traced from a business need to a tested feature, which mattered in a product where calculations drive executive decisions.
- A requirements traceability matrix linked business requirements to functional requirements, use cases, user stories, test cases and releases.
- Roll-up and scoring rules, such as how key results combine into objective progress and how project status affects goal health, were documented as business rules and tested with worked examples.
- A glossary fixed the meaning of terms such as goal, objective, key result, KPI and initiative, since clients used them differently.
- Features deferred from the MVP were kept in a prioritized backlog with their rationale, so the roadmap was clear for later releases.
Which BA techniques and tools did we use?
Techniques
- Stakeholder interviews
- Document analysis
- Data and hierarchy modelling
- Business and functional requirements
- Use case modelling
- MVP prioritization
- User flows
- Wireframing
- Business rules analysis
- Dashboard and report specification
- Non-functional requirements
- Test scenario design
- Requirements traceability
Tools
- Jira
- Confluence
- Figma
- Miro
- Microsoft Visio
- Excel
Results
What were the results?
- 6 levels linked, from vision down to projects
- 9 product modules specified, from strategy setup to permissions
- 5 focus areas in the MVP, from planning to dashboards
- ~9 months from discovery to MVP release
A product that connects high-level vision to daily execution in one place.
- Clear line of sight from every project and KPI up to the goal it supports.
- Faster quarterly reviews, with progress gathered through regular check-ins instead of manual data collection.
- Risks and issues visible to leaders alongside the goals they affect.
- A focused MVP built on clear requirements, wireframes and agreed priorities.
- A new product for the consulting firm that keeps clients engaged with their strategy between workshops.
- A documented requirements base and roadmap for future releases.
“
Lessons learned
What can other product teams learn from this project?
- Define the hierarchy and roll-up rules first. In a strategy product, those rules are the product.
- Agree a glossary early. Teams use "goal", "objective" and "initiative" in very different ways.
- Keep the MVP to the core planning loop: set, track, review. Everything else can wait for real usage data.
- Design dashboards for the review meeting, not for the database. Leaders need status, trends and exceptions, not every record.
- Test calculations with worked examples. A wrong progress score undermines trust in the whole tool.
Does your strategy survive the planning workshop?
Talk to a senior business analyst about defining a product that turns strategic plans into tracked goals, OKRs, KPIs and projects.
Core Strategy: Strategic Planning and OKR App
Project Description
The Core Strategy App was designed to help organizations streamline their strategic planning efforts—bridging the gap between high-level vision and day-to-day execution. The platform enabled teams to align goals, track OKRs, monitor projects, and visualize strategic progress through intelligent dashboards and reporting tools.
Delivered Value
- Captured and structured detailed business and functional requirements to define core app features
- Collaborated with stakeholders to prioritize MVP features and created user flows and wireframes for strategic planning, goal tracking, OKRs, and project oversight
- Outlined use cases for KPI tracking, risk and issue management, and aligning goals with organizational capabilities
- Created test scenarios and supported QA teams during validation
- Led the design of interactive dashboards and reports, including OKR summaries, SWOT analysis, and cross-company strategic insights Ask ChatGPT