Vivek Shenoy

Focused on Marketing, Technology & Product

The importance of scope definitions

Most people, associate the scope of the project with efforts – either as time or cost. While the scope does impact efforts, it goes beyond just that.

Defining the scope of the project has a direct bearing on what is to be achieved in the project. It also, crucially, provides a common understanding and consensus on what is to be included or excluded. Once this has been established, effort estimates are determined. | IT & Marketing Consultant


How is scope different from requirements and SRS?

The previous post detailed what an SRS and requirements documentation was about, and what it achieved.  Without scope, requirements could go from being a simple implementation to a far more complicated one.

As an example, the development team is to build a work flow that allows for the publishing of a blog post. Without a scope definition, this feature could easily balloon to become a guest author or user contributed program – like the one on or Business Insider. While these programs are manual, in the sense that contributors need to email submissions, the content management system (CMS) will require to provision for it. Such provisions could include:

  • Author profiles for contributors
  • Notifications to contributors for comments, updates, etc.

It also helps reduce ‘scope creeps’ – a phrase typically used to explain this ballooning of requirements.

On multiple occasions, the attention and focus I gave to scoping projects, gave multi fold returns. With one client, for whom we were developing a new custom CMS, we had anticipated certain feasibility issues in content migration. Issues included a new taxonomy that required manual re-classification, and multiple formatting issues. Having had included this in the agreement, the exposure to scope creeps were reduced. And, this in turn, helped ensure more predictability in delivery.

(Project Perfect has a nice writeup about defining scopes. )



Interviewing Stakeholders and Product Users

Product definitions are often the function of users. And, it’s for this reason, interviewing stakeholders and product users is important.

In earlier posts, (here and here), the importance of interviewing stakeholders was mentioned in the passing. Thinking its importance has been downplayed, I figured it needed a blog post of its own.

Who’s a stakeholder?

A stakeholder has influence and authority over the product. Such influence and authority, is often a result of vested interests. Such interests include:

  • a user that engages with your site,
  • decision makers within the organisation or
  • the development team that helps with product implementation.

Stakeholders include a wide range of users, teams and persons that have a touch point with the product.

Interviewing Stakeholders and Product Users


Why should I interview stakeholders?

Not knowing what a user wants, or how they want to interact with your system, could lead implementation astray. Understanding needs and wants are good product management practices.

How do I interview a stakeholder?

To conduct such interviews, is challenging. While most of the challenges involve understanding what they want, it also includes logistical hurdles.

Interviewing Stakeholders and Product Users - Dilbert

Source: Dilbert (

Here’s a typical approach to interviewing stakeholders:

  • Identify key stakeholders – Key stakeholders have significant impacts on the product. Example: An SEO focused team mate has requirements that range from URL structures to meta information.
  • Schedule meetings – Before meeting, share the context, and prepare preliminary questions. This will help when interviewing stakeholders and product users.
  • Functional walk through – When meeting a stakeholder, have them first explain their function. Also, have them include various touch points or dependencies on the product.
  • Document requirements – This is, often, an underrated part of interviewing stakeholders. Documentation helps posterity, and is the basis for future discussions and feature/road map definitions.

With this process completed, as a product manager, it becomes easier to identify business imperatives and shape the implementation of the product accordingly. Once this is in place, validating it with external user interviews will be key.

The Advent of Book Publishing

Publishing was shaped by writing, paper, and printing. Literacy fueled the consumption of books, and made the publishing industry an ubiquitous part of our lives.

Modern paper’s early ancestors

The Sumerians, probably, invented writing in the 4 BC, and used it as a means to secure royal decrees, religious texts, social codes and other such important matters. While writing began mostly as letters, it soon evolved to longer forms, mostly that of books.

General consensus defines a book as a written (or printed) message of considerable length. Such messages are meant for public consumption, and recorded on materials that are readily portable.

Source: The King List, recording the names of the rulers of Mesopotamia.

Source: The King List,

The origin of books is relatively unknown, as the first books may not have survived. Evidence suggests that the ancient Sumerians, Assyrians, Hittities, and Babylonians, all used clay tablets. Writers from these societies, had remarkably advanced methods of maintaining tablets for larger text. Such methods included using numbers, and catchwords and is very typical to how modern book publishing typically references pages. The use of tablets continued for the next 2000 years, before the Egyptians started invented papyrus.

It all reads like Greek

With the Greeks adopting papyrus, its usage became widespread. The Greeks also made a valuable contribution to adapting and stabilizing the alphabets – the alphabet became an instrument of communication than just a decoration. With Alexander’s reign, the Greeks, who once preferred oral communication, took to writing and maintaining books. Part of the reason, was to enable communication across far flung cities and annexed territories.

The written form became so prevalent, that libraries were a regular feature and present across multiple cities. Greeks were prolific book writers and readers, but ,sadly, only a minority of their books survive.

Source: Figure nine from Clark's 'The Care of Books,' depicting a Roman reader with his scroll.

Source: Figure nine from Clark’s ‘The Care of Books,’ depicting a Roman reader with his scroll.

The Romans, and their book publishing trade

Apart from using Latin, Roman books were remarkably similar to those of the Greek.  Where the longevity of Greek texts depended on copying by succeeding generations of authors and students, the Romans were probably more instrumental in developing a ‘book trade’ – and at a fairly large scale!

Source: Madrid, Biblioteca de San Lorenzo de El Escorial (14th century).

Source: Madrid, Biblioteca de San Lorenzo de El Escorial (14th century).

Roman texts mention of book shops, and large ‘scriptorias’ or places of writing. Such scriptorias were constantly churning out (primarily by using educated slave labour) books for sale. This made books cheaper and allowed for people from lower classes to read them as well. In some cases, books have been narrated by a reader, and written by up to 30 slave copyists at one time!

This ingenuity doesn’t stop here. Roman publishers, in all probability,  were probably the first to commission works. Roman publishers selected manuscripts to be ‘published’, and paid advances  to authors for rights. And, like most modern publishers,the publishers would determine the format, size, price and develop markets for them. The Romans had established the beginnings of the book publishing industry.

Requirements, SRS and Documentation

Understanding user requirements (or a client’s) is critical when developing a software proposal. And, often it’s a single point of failure.

With most IT and software projects, there is sign off before the actual coding or implementation begins. And, this holds true, whether it’s a project that an IT services company develops, or a product that the internal development team works on. Either way, a requirement document is paramount for software development.

Before, I go further, a few clarifications:

  • With executing a project for a client, the requirements documentation helps define the scope of a project, and also software requirements specifications (SRS)
  • In the case of a product, these requirements manifest as the functional (and at times technical requirements) that appear as line items/tasks in a sprint

What is an SRS, and why is there a need for requirement definition?

The SRS is a software requirements specification document, that provides a description of the application/software to be developed. It details out the functional and non-functional (read: technical) requirements, along with use cases. When executing a project for a client, the SRS often becomes the basis of the contract/agreement between the the parties.

Delivering right, without over engineering 


Rube Goldberg's - Self-Operating Napkin

Rube Goldberg’s – Self-Operating Napkin (Source: WikiCommons)

Much like the self-operating napkin, some times, teams get carried away when developing a feature or implementing a functionality. Take for example, a client of ours that wanted a website built. One small feature on the website was to be the ability for visitors to see what content was popular. And, it was to be achieved with minimal development effort (it was a marketing activity, and the budgets were on the lower side).

The initial approach (and probably the right one, from the long term perspective), was to create social logins, add a five star widget, and store ratings per user in the database. With a view to keep efforts on the lower side, we decided to strip down the functionality to include only a  Facebook login, and a like button for indicating popularity of the content. Doing so helped save a few days of effort, along with the design and testing overheads.

This is, but, one very small example. Entire projects have been undone by not defining the bounds and scope of what has to be developed. And, it’s how well you define requirements, that allows development teams to detail an SRS effectively.



Course Correction

Before focusing on the product development process, a course correction was in order.

The first few weeks were focused entirely on understanding the product concept, the current development process, interacting with stakeholders and understanding how they worked, and undertaking an extensive competitive intelligence exercise. Based on this analysis, a course correction was very much needed.



Like with an airplane making a course correction, a requirement analysis and assessment needs to be made as to what is the best route to take to close that gap. To help identify this route (in our case what to implement), it was an honest assessment of what our product is, and isn’t.

The first step toward change is awareness. The second step is acceptance.
Nathaniel Branden

But before that happened, we first needed everyone to acknowledge that we are drifting off from where we should be. For us, this acceptance came easily (owing mostly to a culture of openness). With that acceptance, we quickly re-prioritized our development road map and worked to close the gap. And, we did.

However, there have been multiple product based businesses, where this was not the case. And, it didn’t end well for them.

It’s always prudent to constantly assess where your product is, in comparison to the industry.

Page 4 of 6

Powered by WordPress & Theme by Anders Norén