No results found

Flipping Rocks, Building Starships and Connecting Cities: Brightcove Goes the Distance for Custom Solutions

Flipping Rocks, Building Starships and Connecting Cities: Brightcove Goes the Distance for Custom Solutions

Flipping rocks, building starships and connecting cities. At first glance, these items might not appear to be connected; but in this blog post, I intend to show how they are vital to the process of creating solutions for our customers.

And what do I mean by solutions, exactly? At Brightcove, we define a solution as something that is not out-of-the-box. A custom solution might entail a specialized publishing workflow, an app that allows customers to monetize video via a paywall, a branded website that displays a contextual video player from assets stored in Video Cloud or a myriad of other imagined concepts.

Flipping Rocks


I was a curious child. Have you seen those commercials where exasperated mothers are pestered by a small child asking "Why?" repeatedly? Yep; that was me.

Things haven't changed all that much. In fact, the first part of Brightcove's solution process involves a discovery phase and is where we in the solutions group get to channel our inner three-year-old, curious child. How so, you may ask?

We want to flip over as many proverbial rocks as we can--as early as possible in the project--to make sure there are as few surprises as possible during development. By engaging with our customers frequently, we validate assumptions and confirm that what we will be creating is precisely what the customer expects.

Building a Starship

Ok, I admit. I could have easily sketched a house and then just shown the blueprint of a finished house design. But that doesn't illustrate the point, nor win any nerd points. Starships may well be the future; but we don't know (yet) how to build them.

Similarly, custom solutions address business problems that our customers have when software does not (yet) exist to solve those problems.

We start out by sketching a solution:

And then, through methodical discussions with the customer, we transform that sketch into a blueprint of sorts.

I say "of sorts" because the finished solution that is delivered is never exactly the same as the blueprint. It adapts throughout the course of the project as needs change and as we "flip" additional rocks.

In reality, these blueprints are called solution proposals and they can contain elements such as:

  • Overview and scope of project
  • Assumptions
  • Components and configuration
  • Architecture
  • Flow diagrams and workflows
  • Use cases
  • Deliverables

Connecting Cities


Within an organization that delivers custom solutions, there are usually many groups that need to take part in the project. Some may be involved in the design process while some will validate the solution. Others will build and QA the solution, while a final group might perform user-acceptance testing and deliver the final solution.

Within Brightcove, there are solution engineers within the sales group that are responsible for creating the solution proposal and validating it with the customer. It then becomes a living document that is normally passed to the consulting organization for transformation into a statement of work. In order to ensure project success, it is important to build a strong bridge without rotting planks resting on rusty rails.

As the team generates the solution proposal, it flows from one "city" to another. It is peer-reviewed and then proceeds through an internal process that guarantees that it contains:

  1. Options – PERT analysis that includes solution alternatives
  2. Alignment – Each solution is reviewed by a steering committee so that any dependencies on the product roadmap are identified and managed.
  3. Risk assessment and a mitigation plan

This process ensures that the connection between all groups ultimately look like the solid bridge above and not the former.

In summary, by flipping rocks and creating solid blueprints and bridges between groups, we lay a strong foundation for a project before ever writing the first line of code.