As with any large operation, developing a product begins with sketching out or planning the idea. Think of it a bit like learning to swim before you proceed to learn to do full laps or dive into the deep end of the pool. Or brainstorming an idea thoroughly so you have a sense of how it can take shape across aspects – story arc, conflict, characterisation, climax, resolution – of it, before you write a longform story or piece of fiction.
Speccing is a vital first step – perhaps the most critical and often underestimated step – of any product development lifecycle. This is where a blueprint is drawn, outlining the nascent details of what the product is, what will be built, what needs it will serve, how it will look, how it will be used, who will use it, and any other specific functions that it may be designed to serve. Essentially, this is the foundation upon which the product is then built
While marketing and branding exercises begin with a brief, at Flooid the speccing stage is characterized by building what we call an Intent Document. Arriving at this is an exercise in understanding not just the requirements of the product to be developed, but also to get our teeth into understanding deeper business implications in the environment that the product will eventually be in.
A two-line brief is as good a place to start as any, but it can inaccurately make product management work sound like a piece of cake. Without spending enough time and effort understanding various scenarios contributing to the need for a product, defining the problem a product will help solve, various corner cases that might emerge, perhaps even financial implications for the business, and more, it can often feel like diving in the deep end without learning to swim first. And for the development cycle it can be like starting in the middle and going back and forth without clarity, rather than having a point of focus and working towards it.
The Intent document goes beyond merely listing specific features that the product requires, to enumerate broader details like the business objectives of the product, how and what metrics will be used to measure it.
The ABCs, basically:
- What are we building?
- Why?
- What are we trying to achieve/solve?
- How can we measure our success?
This is the stage at which we bring in user stories – specific, user-centric perspectives that shed light on what the user would possibly want to see, use or benefit from in the product. We take on the laborious, but essential task of building step-by-step flows for each user journey, to ensure that we go beyond the commonly explored happy flow, and cover other possible edge cases as well, making the user-journey/is more comprehensive
At this stage we also:
- Plan for validation and the testing that is to be carried out at each stage of the development cycle
- Explore and firm up the logic for calculations, if any
- API fields that are to be consumed/created
- Interactive pieces like error messages, nudges, prompts that are clear and understandable for the specific user that will see them
This might seem like a very tedious exercise to undertake before a project has even taken off. But the truth is, speccing is not a one-time activity. The more robust a spec document is, the deeper/broader our understanding is. It helps cover more ground so design delivery is more and there’s lesser scope for surprise or errors along the way.
While we benefit from going in-depth at the start of the project, the spec document is continually evolving and gets updated through the lifecycle of the product development, to reflect the real-time changes as they emerge.
We’ve seen that covering the bases thoroughly at this stage is crucial to ensuring successful delivery. In cases where the speccing process was not given adequate importance or done haphazardly, development time was inevitably longer, laborious for all parties involved and invariably led to wasted time, multiple iterations
and frustration.
Clients may react more favorably to visuals, or wireframes and designs that are somewhat tangible, and give something to sink their teeth into. A long-drawn speccing activity on the other hand may seem dry and like too much effort too early in the project. But this is the foundation where the real work happens. It’s how we can ensure all features are covered, and that we can strike a balance between the must-haves and the nice-to-haves. In the chase to build too much too soon, without focusing on that deep, sturdy foundation, the product runs the risk of becoming a hollow, shaky version of what’s really possible.