Product Roadmap

Background

The Contour product has niched into the pre-sales to delivery handoff between solutions consultants and technical architects primarily from the SOW to the TDD. To scope out a little bit, the process of consultants today is

  1. A client will go to a few consultancies with an RFP(request for proposal)
  2. The consultancies will return a proposal + a ROM (rough orders of magnitude - a simplified pricing doc)
  3. The client will choose a consultancies proposal and verbally commit to that consultancy
  4. The consultancy will spin up an SOW contract and get it signed off on and the deal will commence
  5. The delivery team will pick up the contract and draft a TDD and start working on the project Steps 1-5: All the while generating and refining a BRD - The hire the fidelity the BRD is earlier in the Sales process the better the SOW scoping and TDD scoping is going to be.

Hence, the core artifacts that will eventually be developed by Contour is the proposal (including the ROM), the BRD, the SOW and the TDD.

RFP - Client requirements doc Proposal - Sales doc on why the client should pick the consultancy ROM - Rough pricing doc BRD - Solution agnostic requirements for the business typically created through discovery targetted at the bizops stakeholders - The reason this is oftentimes not done well before the SOW is because the pre sales process is competitive and asking the client to pay for a paid discovery while competitors might not is tough. But a well written BRD before the SOW can go a long way for CO reduction. SOW - Contract for what will be delivered - targetted for legal, procurement, stakeholders TDD - Delivery team design doc for how it will be delivered.

Goal

What pain points have really resonated with current design partners?

  1. Senior consultant or Subject matter expert time in pre sales (before the consultancy is getting paid)
  2. Accurate scoping

Pre Sales Cost

The main point of this is to reduce spend during the pre sales pre SOW signing step. The two ways to do cost reduction are

  1. Automate away the junior person’s time in terms of generating the artifacts (Proposals, ROMs, BRDs, SOWs)
  2. Reduce the amount of input that needs to go into the artifact generation and discovery from the senior consultant.
    • The senior consultant could either
    • have input in the artifact generation so better artifact generation should lead to less senior consultant time
    • OR be posted on calls to ask the right questions and maintain the relationship (asking better questions solves this pain)

The two actionables here boil down to the same end state deliverables. Which are to understand what context is required to generate a really good artifact and be able to parse that content out of the sea of unstructured data.

Accurate Scoping

If projects aren’t scoped properly, there will be change orders to rectify what’s needed as addendums to the signed SOW. The results of this would typically be

  1. Timeline or scope creep - Sometimes the consultancy will eat costs if it was miscoped on their side.
  2. Lower CSAT scores - Customers will think they agreed to a price for an engagement then get charged much more

From a process perspective what leads to scoping drift?

  1. If at the point the SOW is signed, the BRD is immature and doesn’t truly encapsulate the clients pain, the scoped contract might not solve the business problems causing an incorrect build - this is a scoping problem of are we understanding the customer business properly
  2. Poor SOW to TDD delivery handoff - wrongly scoping what it takes to resolve what’s on the SOW, eg on manpower/time/cost.

If this understanding is correct then all change orders should be attributable to

  1. Missing/incorrect detailing of the BRD leading to missing or incorrect sections of the SOW
  2. Wrongly estimated quotes in the SOW for correct solutions to the BRD that manifest in later realizations either when creating the TDD or in actual delivery/certinia.

Change orders are the signals that we train against for things going wrong from BRD <-> SOW and SOW <-> TDD. In order to properly handle accurate scoping, we should essentially root cause every change order ever and relate those to factors in our world model (introduced below) that caused the change orders to pattern match in the future.

So how can we improve the scoping accuracy? I see the solution to this as building a strong cross artifact world model for customer pattern recognition. IF we could somehow say these past 8 implementations are similar each along this vector have the same issues as this new implementation and you’re likely missing x requirement that will trigger xxx$ change order soon that would help tremendously with scoping accuracy.

If we’re to break down the building of the world model into subproblems they would be similar to the necessary subproblems of creating good artifacts in the first place.

  1. Defining the entities that matter that should be used as pattern recognition vectors - Try to avoid modelling everything in the document, I bet most going to be noise
  2. Accurately retrieving those entities and contextualizing them.
  3. Recognizing patterns

Tangible Roadmap Steps

Phase 1 - Pre Sales Cost Optimization + Improved Claude

  1. Build out the data models for the skeleton of good artifacts. These are the entities, quotes, estimates, promises and building blocks that can be used to construct a good artifact and how they relate to each other.
  2. Attribution and search/retrieval. Being able to pull out the right search and retrieval and contextualize that into the above data models. The goal is to be able to index all incoming transcripts and documents for important information with high confidence and build out the skeleton from step 1. This should be our agent eval framework. It will determine how good our citations are, how good our artifact section writing is, how accurate our BRD requirement to SOW scoping translation is.
  3. Artifact generation - Building out the BRD, SOW and TDD to start. This is combining all the above contextualization, with templating/historical context of how the prose should be structured. The goal is to have fully useable artifacts that are the SAME quality as historical artifacts but now with sources, citing, and potentially contradictory stakeholder analysis.

Phase 2 - Self Improving System

  1. Change Order analysis - Indexing the change orders and connecting them with our data models to run classical ML against why they happen in the first place. This will augment our artifact generation and risk flagging for artifacts.
  2. Discovery Requirements retrieval - Meeting bot for asking the right questions that inform the BRD/SOW. This is based on historical indexing of understanding how parts of the BRD converted to specific scopes in the SOW + change orders on how things in the BRD were missed/mistranslated to the SOW. After this step, our questions lists should only be the minimum subset of questions and answers that are necessary to scope the BRD and SOW (we’ll know which questions don’t usually lead to parts of the SOW).