The first step in building a SMART (Substitutable Medical Applications, Reusable Technologies) application with FHIR (Fast Healthcare Interoperability Resources) compliant EHR (Electronic Health Record) is identifying an authentication and authentication strategy. Fortunately, SMART on FHIR lays down very specific guidelines to do it. It proposes to use OpenID Connect and OAuth 2 for authentic and authorization respectively. If you are building a new application, there is a high probability that it supports OAuth 2 and Open ID Connect. Let’s take a quick look at OpenID Connect and OAuth 2.

OpenID Connect and OAuth 2.0

OAuth 2.0 is a widely used standard for authorization. It helps identify what a user can do in the application. It is very simple and interoperable between web, mobile, and desktop applications.

OAuth 2.0 allows users to use their trusted application as the main identity provider when they authenticate with other applications. A real-life example that you might have experienced is ‘Login through LinkedIn’ or ‘Login through Google’.

Following diagram shows how actions flow through it -

While OAuth 2.0 is used for authorization, OpenID Connect is a layer on top of that for authentication. It helps identifying ‘who’ a user is.

Following parties are central to OAuth 2.0 and Open ID Connect-

Resource owner — Resource owner could be an end-user or a machine if no human interaction is involved in accessing the resource.

Authorization server — At its core, an authorization server is simply an engine for minting OpenID Connect or OAuth 2.0 tokens. Authorization server has its own unique URI.

Resource server — Server where the resource (data) that needs to be accessed is located. In case of integration with FHIR based EMRs, those systems will be the resource server.

Different ways to connect third party SMART apps with EHR

While wiring up authentication and authorization, it’s important to keep in mind the various launch schemes. SMART app’s can be launched in multiple ways. SMART specifications provide a launch framework to connect third-party applications to EHR data. This allows for apps to launch from within the EHR or outside of it as a standalone app.

The Launch Framework supports the uses cases as defined for Phase 1 of the Argonaut Project:

• Patient apps that launch standalone
• Patient apps that launch from a portal
• Provider apps that launch standalone
• Provider apps that launch from a portal

Launching SMART App from within EHR

Apps can be launched from within the EHR by opening through a preconfigured launch URL into a new browser tab or within an iframe. Context such as patient record, or facility required for appointment manager is passed through URL.

Launching SMART App as standalone app

In this case, the app first goes to the FHIR server of the EHR to get the metadata. Using this metadata app then authorizes the EHR authorization server. Once scopes are identified, the app uses those scopes to get the data (patient or clinical user or any other data specified in FHIR specifications) from the EHR server.

Managing access to the data

SMART on FHIR apps uses OAuth scopes to communicate access requirements with the EHR. Apps that need to read existing data from an EHR should ask for read scopes. Apps that need to write data to an EHR (e.g., FHIR create, update, and delete) should ask for write scopes.

In general, scopes can be used for three kinds of data:

Clinical data: To access the clinical data of patients we have following scopes:

Contextual data: Generally, SMART apps will need a context to provide seamless integration with EHR. E.g.

- Patient record in the EHR

- Encounter in the EHR

- Location (hospital or facility) from where clinical user is logging in

There are two approaches to pass context from EHR to SMART app:

1. Apps that launch from the EHR: They will be passed an explicit URL parameter called launch. For example — launch=abc123
2. Standalone apps: Once an app is authorized, the token response will include any context data the app has requested

Identity data: To authenticate and fetch the details or profile information of clinical end-user, “openid” and “fhirUser” OpenID connect scopes should be used.

The Mechanics of Authentication and Authorization

Registering the app in EHR portal

We need to register an app with the EHR to access its FHIR resources, or to use it for authentication or authorization. Most of the EHR’s that support FHIR, provide a portal where we can create the app. We need to provide the following information to the EHR for creating the app.

After the app is registered, the EHR will provide the client_Id which will be a unique identifier of our app registered in the EHR portal.

Authentication workflow and token generation for each of the workflow

Step 1: The client application is launched from the patient portal or EHR

The client app is launched by the EHR with the launch URL of the client application specified in the EHR’s configuration. The EHR sends a launch token and the FHIR server’s endpoint URL (ISS parameter).

launch: This is a token generated by EHR and signifies that an active session already exists. This token is one-time use and will be exchanged for the authorization code.

iss: This parameter contains the authorization server’s FHIR endpoint URL.

Step 2: The client application retrieves the conformance statement

To determine which authorized and token endpoints to use in the EHR launch flow, make a GET request to the URL which is constructed by taking the ‘iss’ provided in the above step and appending /metadata at the end.

Step 3: The client application requests an authorization code from EHR

After getting the launch token from the EHR, make a request to the EHR authorization server on the authorize endpoint. This request will exchange the launch token for an authorization code. Append the following querystring parameters to the request:

response_type: This parameter must contain the value “code” that represents the client application which is requesting authorization code.

client_id: This parameter contains your web application’s client ID issued by EHR.

redirect_uri: This parameter contains your application’s redirect URI. After the request completes on the EHR server, this URI will be called as a callback.

state: It’s useful in case you want to restore the app state after login, since the whole app unloads or unmounts when the OAuth screen opens, and you might need to redirect the user to the right protected URL where they were trying to login.

scope: This parameter describes the information for which the web application is requesting access.

Here’s an example of an authorization request.

https://example.com/oauth2/authorize?response_type=code&redirect_uri=[redirect_uri]&client_id=[client_id]&state=[state]

Step 4: EHR’s authorization server reviews the request

The EHR’s authorization server reviews the request. If the request is approved, the authorization server redirects the browser to the redirect URL supplied in the initial request and appends the following querystring parameter.

code: This parameter contains the authorization code.

state: This parameter will have the same value as the earlier state parameter.

Step 5: Request for access token

After receiving the authorization code, make a POST request to the EHR for the access token on the token endpoint.

The following parameters are required in the POST body:

grant_type: For the EHR launch flow, this should contain the value authorization_code.

code: This parameter contains the authorization code.

redirect_uri: This parameter must contain the same redirect URI that was provided in the initial access request.

client_id: This parameter must contain the application’s client ID issued by EHR that you provided in the initial request.

Here’s an example of what an HTTP POST request for an access token might look like:

POST https://example.com/oauth2/token HTTP/1.1

Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code&code=yfNg-rSc1t5O2p6jVAZLyY00uOOte5KM1y3YUx&redirect_uri=https://test.com/test/smart&client_id=d45049c3-3441-40ef-ab4d-b9cd86a17225

The EHR responds to the POST request with a JSON object that includes an access token.

Step 6: Request for patient data

With a valid access token, the client application can now request patient or other protected data from the EHR.

Persisting and refreshing token

Refresh tokens are not typically needed for embedded (SMART on FHIR) launches because users are not required to log in to EHR during the SMART on FHIR launch process, and the access token obtained from the launch process is typically valid for longer than the user needs to use the app.

Conclusion

If you are planning to build a SMART app, implementing FHIR OAuth2 is easy to implement and allows seamless signon. If you want to convert an existing app into a SMART app, even then SSO won’t be a difficult thing to do as long as your app supports OpenID Connect and OAuth2 for authentication and authorization.

I wrote this blog for our Medium Publication- Unboxing Product Management. The publication is a weekly column by people of Quovantis to share their learning.

How to do seamless sign on (SSO) for integrating SMART app with FHIR compliant EHR was originally published in Unboxing Product Management on Medium, where people are continuing the conversation by highlighting and responding to this story.

We all have heard stories of successful innovations that changed the world. We’ve also heard the number of times these innovators failed, but persevered. Whether it was Thomas Edison, Walt Disney or Henry Ford, almost every story mentions how these people remained unperturbed to failure and kept trying.

Fast forward to present day, there is an increasing number of companies who are investing in building an innovative culture. Much like Google and Apple, organizations are building innovation centers, R&D buildings, and Think Tanks to motivate employees to come up with new ground-breaking ideas. Alas! What they don’t see is that innovation thrives on discipline of execution.

Let me explain.

Trying to innovate without any set boundaries on timelines or outcomes overwhelms people with options. They keep looking for an elusive ‘best solution’ and ignore putting in daily labor to produce results. Without any structure in activities, or any discipline in maintaining the relevant efforts towards doing innovation, organizations/individuals often fail to produce desired results. Innovation, for them, becomes just another activity, devoid of any action. It eventually becomes a task to disconnect from the mundane and spend some free time mulling over the fancy idea.

HBR in an article on “the hard truth about innovation” also touched upon this topic and said-

“Innovative cultures are misunderstood. The easy-to-like behaviors that get so much attention are only one side of the coin. They must be counterbalanced by some tougher and frankly less fun behaviors.”

So, how can organizations embrace a more disciplined approach to innovation?

Accept failure, not drudgery or incompetence

There is no denying the fact that one master-stroke of innovation goes through multiple rounds of failure. And that’s understandable. Like Edison said- “I have not failed. I’ve just found 10,000 ways that won’t work”, innovation truly requires tremendous patience in attempting, failing, and never giving up on the task.

But what we shouldn’t overlook is that every failed attempt must turn out to be a valuable lesson in the explorations ahead. Otherwise, what’s the use of repeating the same mistake again and again? Moreover, the tolerance for accepting repeated failures may give way to people making lame excuses and showing sluggish progress quoting that they’re onto something big, something that takes time!

Failure to produce desired results also stems from declining motivation to work on the project, lack of transparency on the expected outcomes, mismatch in skills required to execute the project or sheer drudgery.

The only way to come out of this situation is to maintain a level of competence required for the job and allowing only those people to be on the team who adapt, learn and deliver results at any cost.

Therefore, if you’re in a position to make decisions, always leave room for failure, but not for incompetence.

Make people/teams accountable for outcomes

Basecamp gives it employees an entire month off (every 3 years) to work deeply on their own projects. At the end of the month, the company holds a “pitch day” where everyone presents their ideas. So, it’s not just a corporate fad to attract employees. It’s rather a genuine attempt to empower people to work on innovative ideas within a restricted timeline in order to produce maximum output. It’s a great idea to hold people accountable for the outcomes they generate.

Moreover, accountability allows people to take ownership of the tasks and see the gaps in what they imagined v/s what they’ve accomplished so far. As a result, when people are held accountable for producing something tangible, they produce better results.

Another positive side of accountability is that it speeds up decision-making. When people know they’ve promised an outcome, then they learn to be confident decision-makers, rather than waiting for someone to make their decisions.

Criticize brutally (and candidly)

One of the many reasons why innovation never materializes into something real and functional is because we humans like to avoid getting into difficult conversations. If someone is not performing as per expectations, or if someone is not self-directed in accomplishing his/her goals, we find it difficult to reprimand and speak the truth, just to preserve the harmony of the workplace.

Jeff Bezos too believes that harmony is often overvalued in the workplace — that it can stifle honest critique and encourage polite praise for flawed ideas.

Therefore, make sure that you are not caught up in the niceties and speak your mind. Criticize and seek criticism, but never let someone pass of their mediocre work as great.

Allow people to daydream, but with discipline

It’s in human nature to build castles in the air and dream about various possibilities that can exist. But innovations are rarely built on imaginations. Yes, they do begin to take shape from creative thoughts, but innovative teams need rigorous discipline to deliver possible outcomes.

Let’s look at it with an example. You’re building an employee engagement tool for use within the organization. There are numerous ideas from everyone on the team regarding what features the tool should have. Now, obviously one can’t move ahead with every idea. Every team member must sit together for a decision on whether to implement, modify or reject the idea. Once there is a consensus on which ideas should be implemented, strict timelines (2-weeks from now) should take place of vague dates (sometime in the end of the year).

Discipline-oriented innovative cultures bring more cadence in the team and translate into better creativity.

Bring in transparency at all levels

When a big idea takes shape, it involves a lot of team members from various parts of the organization. While it’s important to maintain modularity in functioning of each team, an even more important thing is to maintain the communication between each stakeholder.

What’s in progress, why something was put on hold, what’s holding back a particular team, why one team is performing better/worse than the other, what release is due next week — communicating all these concerns to everyone in the innovation squad, maintains the level of transparency that’s needed for teams to deliver faster results.

This helps the team members in entrusting their leadership and management to take the right decisions for them.

I wish I had given this disclaimer in the beginning of the post. Nonetheless, here it is — building a culture of innovation in organizations will never be easy.

Even with the suggestions listed above, you would find various factors inter-playing and slowing down your progress. The only way to deal with it is to go back to the purpose of your innovation and keep your team motivated about it.

I hope you find my suggestions helpful in building a kick-ass culture of innovation in your organization.

I wrote this blog for our Medium Publication- Unboxing Product Management. The publication is a weekly column by people of Quovantis to share their learning.

Why building a culture of innovation is incomplete without implementing discipline of execution was originally published in Unboxing Product Management on Medium, where people are continuing the conversation by highlighting and responding to this story.

You would have often seen product managers grappling with tons of issues related to product development. Whether it’s design or marketing, strategy or execution, product managers are always bridging gaps between ideation and execution.

In between all that chaos, PMs often leave the responsibility of handling the technical aspects of product on the engineering manager. That makes sense, because the scope of product management is huge and one PM can’t possibly handle everything.

However, there is one aspect of product development that I wanted to touch upon.

Handling technical debt.

Some of you might argue that handling technical debt is the responsibility of the engineering manager, not product manager. And I couldn’t agree more.

But here’s a quote that made me rethink my stance on this topic.

“Technical debt isn’t directly responsible for the failure of a startup. However, if ignored it may become one of the causes of a startup’s failure.”

The first time I heard it, I casually shrugged it off. But then I kept hearing it again and again until I decided to delve deeper and find out how exactly Technical Debt affects product’s success. Because anything that has an impact on product’s success should concern a PM.

If you’re a Product Manager who is currently handling a development cycle, or if you are aspiring to be a Product Manager, this might be interesting for you. Read on!

What is Technical Debt?

Technical debt is a metaphor which was coined by Ward Cunningham. It signifies the debt that a product acquires when the product engineering team deteriorates and overlooks the quality of the code consistently over a period of time (not always intentionally)

But that’s not the only reason. Software systems are prone to Technical Debt. Debt can creep in due to various reasons. It can be due to the forceful (& hasty) decisions that the team takes in order to ship products faster (planned technical debt). A planned technical debt usually comes into the picture when the teams are bound by deadlines and project release can’t be pushed under any circumstances.

For example- “If we don’t release this MVP in December before Christmas holidays, we’ll be screwed. So, let’s tightly couple these two components for now. We know paying technical debt is important too but let’s take it up after the release.”

The other kind of technical debt — the unintentional, creeps in without knowledge when the team cuts corners by investing in suboptimal architecture/technology solutions. Sometimes, it also appears because the engineers don’t know the best practices of writing a code, or , the QAs are not aware of the best practices to test the code.

How technical debt affects product success?

Technical debt (if not handled in the right manner) can impact the following in adverse ways -

Productivity and happiness of developers

If the engineering team spends a good portion of their time rewriting and debugging the previous code, their productivity and morale is bound to take a hit. Imagine yourself in their shoes and think about how would you feel if you’re hired to clean other people’s mess and make little contribution in writing new code.

Quality of product

Having a huge Technical debt also affects the quality of the product. In simple terms, technical debt is something that is suboptimal in the current scenario. It is something that should not have been there. Or, should have been fixed. Therefore, the greater the technical debt, the higher the chances of product not behaving in the best of ways.

If there are too many lines of code for a simple feature or too many callbacks to a single function, it will affect the loading time on page. And no matter how pretty your product looks on the app, your users will not like it if it’s slow.

Speed of feature implementation

Once your product is live in the market, you would need to act fast and develop more features to keep your users happy. You would also need to fix the errors of the previous version in the new build.

But Technical debt will greatly reduce your speed of execution because every new feature would require an extra time (thus extra cost) to handle the previous mess created in the code.

User happiness

Technical debt lying somewhere in the code is like a ticking bomb. It can cause unexplained or random errors in production. If anything of this sort happens with the user, it will lead to distrust and unhappiness.

Brand reputation and growth

If your codebase has a lot of technical debt, side-effects won’t be good at all. As I have mentioned in the previous point, it can cause random errors in production, leading to poor user experience. If this happens a few times, it will generate discontent among users and lead to loss in the brand’s reputation.

If you’ve seen the HBO show Chernobyl, you’d be able to easily relate technical debt to product development.

There are plenty of real life instances where Technical Debt crippled a company’s growth (but didn’t halt it). The companies still made it big, but they had to invest millions of dollars to fix the problems.

Early Twitter users may remember the iconic Fail-Whale error page. It’s a reminder of the time when Twitter didn’t live up to the world’s expectations. It took many months for them to re-architect and build a scalable solution.

How can product managers resolve the technical debt conundrum?

For a moment, let’s assume that your Engineering manager comes to you and says that the debt is unsustainable and the team can’t proceed any further until they spend the next 2 sprints in managing it?

How would you react in such a situation? Would you proceed with the feature development focusing on the release? Or, would you stop and pay heed to the Engineering manager’s advice of paying technical debt?

Or, is there a middle way out?

Let’s see.

When I was put in one such situation, I personally felt bad (because the word debt evokes a negative emotion) and my immediate urge was to pay back this loan and get it over with. But I didn’t let it overpower me. So I decided to hold the technical debt as is and moved on with new feature developments instead. My rationale was — why spend time and money on something that is not going to generate direct value for the customers?

Another project, another time, we had to halt the development process completely and pay the price of ignoring technical debt. Our entire engineering team spent nearly 6 weeks to change the structure of the code to bring it to the point from where we could pick new features again.

Lesson one: Technical debt isn’t a fake monster, it is a real one. Unless tamed, it can derail your features juggernaut very quickly.

In another situation, when we decided to spend dedicated hours within the sprint to handle technical debt in parallel, we compromised on our speed to market and didn’t ship even a single new feature in close to two months.

Lesson two: End users of the product don’t care about how you deal with technical debt. In the competitive market, only one thing matters — innovation at lightning speed.

After these two experiences, I learnt the two most important things as a product manager-

Focus on reducing technical debt, but don’t stop innovating

There are no second thoughts on Technical debt being an evil. You can’t completely ignore it. You can either pay it in parallel or later when it cripples your growth entirely.

So, in my opinion, the best practice is to always allocate a portion of time refactoring (say 15–20%). But that might also depend upon the state of your product and the amount of technical debt. Encourage your engineers to not shy away from fixing technical debt as they see it. More regularly it is tackled, better it is for overall health and success of the product.

Ask your engineering team to record technical debt in your ALM tool like any other work items. More details, the better it would be. So that you can see everything in the backlog. More items you see in there as TD being added on a regular basis, more worried you should be. Make sure that a chunk of them is being knocked off in every sprint to keep overall magnitude of TD items in check.

Technical debt can never be zero

It’s difficult to make Technical debt zero in real projects, no matter what best practices you follow. And it’s nearly impossible when you’re dealing with legacy systems.

However, there are some metrics that help you define how badly you are doing. For example, SonarQube is a tool that helps you assess vulnerabilities and code smells in your code. It computes the technical debt using the SQALE (Software Quality Assessment based on Lifecycle Expectations) methodology. SQALE is based entirely on rules and issues which flag duplicate code blocks, skipped unit tests or similar issues.

So, as a Product Manager you can ensure that your engineering team is aware of these methods and follows them to prevent accumulating technical debt.

Conclusion

No matter what people say, don’t ever believe anyone who claims that Technical debt is avoidable. It’s not. If anything, you can say that it’s manageable.

As a Product Manager, it might get a bit confusing sometimes, when you have to decide how to deal with Technical debt. In such situations, it’s your technical skills that might prove to be useful.

But don’t worry if you’re not a Technical Product Manager. All you need is a bit of reasoning and the ability to judge what problem will be solved/averted by investing time in reducing technical debt. Or, what value it will create if this technical debt is fixed.

Most of the time, your Engineering Manager should be able to share enough context with you around technical debts so that you can make a more informed decision on which ones to tackle in the release and which ones can wait.

I hope I was able to explain clearly how technical debt and product success are related. And I hope this helps you in making better decisions.

I wrote this blog for our Medium Publication- Unboxing Product Management. The publication is a weekly column by people of Quovantis to share their learning.

How technical debt and product success are related was originally published in Unboxing Product Management on Medium, where people are continuing the conversation by highlighting and responding to this story.

Building an agile team from the ground up involves consideration of a lot of factors. You have a huge responsibility of on-boarding the right people, aligning them with the vision of the product, building the right team culture and making sure that everyone is on the same page with respect to quality.

Every time I get an opportunity to build a new team from scratch, I am engulfed with mixed feelings. I feel excited, because I am given the rare opportunity of kick-starting a great team. But at the same time, I feel scared because somewhere deep down I am aware that one wrong decision can potentially break the team.

In the past, I have made my share of mistakes and learned how I could have avoided them. In this post, I want to share my learning with leaders who might be tasked with similar responsibility.

Below are some of the ways in which I start building a new agile team —

Creating a compelling vision of the product for the agile team

Teamwork is the ability to work together toward a common vision, the ability to direct individual accomplishments toward organizational objectives. It is the fuel that allows common people to attain uncommon results. — Andrew Carnegie

Back in the 1960’s, there was a time when IBM was losing business because the software they were building was of poor quality. To solve this, the management team brought together a group of people who were relatively better at finding bugs than their peers. They called these people “The Black Team”. Now this team had just one task — to find as many bugs as possible and to savage the developer’s code.

I know that sounds pretty villainous, but it actually turned out to be very effective.

But here’s what you should know- none of the Black team members were exceptional testers. However, they had a common vision which made them better than the average QAs. Together they were more effective because they knew if they didn’t do their tasks well, they would lose business.

This is exactly what we need in agile teams- a compelling vision and a mutual feeling of craziness to make the team win. Having a shared vision helps people understand the bigger picture and they work harder than usual to make the project a huge success. So, when you’re building a new team, it’s important that you help them understand what is it that you’ve gathered for.

Another advantage of having a compelling vision is that a good team member would always want to know why working on this product will be the best decision they ever took? They would want to know how this project is different from any other project? How does it impact the human life at large? Some team members would also be interested in knowing how working on this project can help them expand their knowledge and give an opportunity to learn new technologies.

So. there’s a good chance that you’ll onboard some kick ass people in your team because only those who have a thirst for knowledge will be interested in joining you.

Setting up the right culture in the team

Culture is what happens when the boss is not around

Culture, especially in Agile teams, plays an important role. Since Agile teams are self-organizing teams, it’s important that every team member has a common understanding of what is expected from them.

So, it’s upon the leader to set up the right examples in the team with respect to core values that matter to the organization.

For example, at Quovantis, we have five core values- excellence over mediocrity, collaboration over command and control, self-managed over directed, curiosity over complacency, and honesty over impressions. Now, to make sure that the team understands what these core values imply, they must know how to imbibe them in their work. This guidance has to come from the leader.

A few examples- how to make sure that each team member is honest in his/her deliverables and not just pretending to do ‘hard work’? How to help the team understand what is excellence and what is mediocrity? Is the code where only some unit test cases are written acceptable? How to make sure that team members are self-driven to deliver on time?

All of this must be listed down in a document and shared with the team so that they know what’s expected from them.

More importantly, a new team in the forming phase is apprehensive about a lot of things. People don’t feel comfortable in voicing their opinions and are probably holding back a lot of criticism for the process/people. What tasks should the team pick up first? What should they do if they don’t agree with some practices? How can they hold each other accountable? How should they give each other feedback?

So, it’s a leader’s job to ease out the team’s doubts and make them feel comfortable with each other.

Create a skill matrix for the team

It’s possible to fly without motors, but not without knowledge and skill. — Wilbur Wright

A new team with new team members brings an eclectic mix of people from various backgrounds. There is a possibility that they all have previously worked on some other project or probably it’s their first project.

To help them sail through the challenges of product development, it’s important that the product leader must guide them with the right skill set that they must develop. In this case, defining a role-specific skill matrix helps.

What skills are necessary? How to acquire them? Would they be required to learn a new skill in future? Is there scope for personal growth and learning?

The reason this is important is because agile teams embody “we” rather than “I”. So, it’s not just about the team member or the product’s success. Rather it’s about mutually succeeding and improving skills for the future growth.

Formulate team processes

The best teams I’ve encountered have one important thing in common- their team structure and processes cover a full range of distinct competencies necessary for success.— Jesse James Garrett

An agile team is like a child — it grows with time and becomes mature with experience. Therefore, just like in life, it’s important that every agile team has strong pillars of ethics and a disciplined approach to work. At the same time, every team member must also understand the team processes, tools, team rituals, and why they are important.

The reason for this is that when they understand how these processes fit into the scope of things at a high-level, they don’t look at it as just another activity. Rather, they look at it as an impact wielding weapon.

High-performing agile teams have a strong foundation which rest on practices like code reviews, unit test case coverage, sprint retrospectives and regular product releases. So, for a new agile team, take as much time as you want in figuring out which practices you want to follow and then make them sacrosanct.

At Quovantis, our teams ponder over the below team practices/processes-

• Which ALM (application lifecycle management) tool to use? Like JIRA, Azure DevOps etc.
• What would be the workflow through which work will be delivered and deployed?
• How will team do estimations? Which technique they will use?
• Do they need a wiki for collaboration? If yes, what kind of information will go in there?
• How deliverables be reviewed? What would be the guidelines to follow?
• What metrics team will monitor to know about progress and discover risks? Each ALM tool comes with a lot of reports and metrics that team can use for their benefit.
• Which tool they will use for internal communication? Like Skype, Slack etc. No, they all aren’t the same. Carefully choosing the one that suits group requirements will work the best.
• Which tool to use for automating unit and functional testing?
• Which tool to manage action items coming out of retrospectives or other meetings?
• How to manage DevOps? Which tools to use?

There can be many more things that go in the list above. But these is a good enough list to start with.

An agile team, no matter the years of experience, is always in the phase of learning and improving. But it’s true that it’s a bit difficult for a new team to adapt with Agile methodology. Therefore, it’s always a good approach to make a good start and reap the benefits of a highly effective and functional agile team.

I would love to know your thoughts, the tools or processes you’ve used in bringing up a new agile team. Drop in your comments and enlighten us.

I wrote this blog for our Medium Publication- Unboxing Product Management. The publication is a weekly column by people of Quovantis to share their learning.

Lessons from building a kick-ass agile team was originally published in Unboxing Product Management on Medium, where people are continuing the conversation by highlighting and responding to this story.

It’s hard to imagine building a product without a product manager. Blasphemy, I tell you! I tried to think of what kind of a team would that be and I shuddered at the sheer thought it.

Without a product manager, it’s highly improbable that the team wouldn’t crumble to chaos. A product manager helps guide the team through every stage of product development- brainstorming, wireframing, design, development, testing, and takes it to its launch date. Imagine doing all of that with each team member responsible for it.

I don’t intend to say that it’s impossible. Anything is possible if you have the right people in your team. But even a pack of wolves needs a leader.

The early days of product management focused on just the growth of the product. The role of a Product Manager emerged in 1931 when Neil H McElroy of P&G felt that they need somebody to take the responsibility of the brand in entirety. They wanted one person who would take responsibility for improving sales, managing promotions, managing the product along with doing field testing and interacting with users.

After that, HP carried this idea further and interpreted this role as being the voice of the customer. In fact, it is said to be one of the key reasons for HP’s 20% year on year growth for about 50 years from 1943 to 1993!

However, the trend nowadays has changed. Now product managers are associated with literally everything under the sun. If you’re an avid reader, you would have read numerous posts about what a product manager should be. Some of them go and call product managers with fancy names such as-

• Strategist and visionary
• Researcher and analyst
• Communication champion
• Expectations manager
• Technologist (in some way)
• Designer and art lover
• Data cruncher
• Storyteller

In short, a SUPERMAN!

But isn’t that highly unrealistic? To expect all of that from one person? From my point of view, this puts unnecessary pressure on the PM and it makes them feel incompetent if they’re unable to deliver results. I have often seen peers talking about the exasperation they felt- “If this is what PMs are supposed to do, I’m in deep trouble.” 😮

So, I dedicate this blog to talk about what product management is not. I hope future and present product managers learn from it and find it useful.

Product management is not like running a company

And you are not the mini-CEO of your project.

Ever since Ben Horowitz wrote about good product manager, bad product manager and said that “a good product manager is the CEO of the product”, people have begun to build their own theories around it. Although I agree with Ben’s other comparisons, this one, I beg to disagree.

Even if you consider that it’s just a figure of speech and jump to defend that he essentially means that just like CEO is responsible for running a successful company, the PM is also responsible for running and building a successful product- I would still stand against it.

CEOs have a much different role and responsibilities from that of product managers.

👆 A CEO is responsible for setting the overall strategy for the company. Product managers don’t do that for the product; the product stakeholders have that ownership. Most of the times, PMs just follow or help in building the strategy.

👆 A CEO is responsible for setting the vision of a company and making sure that everyone is aligned with it. Product managers don’t do that for the product. Most of the time, it’s the job of founders or CPO to set the vision for the product. Product managers take care of the vision and make sure that the team understands it.

👆 Product managers have no say in building the team. They can’t decide on who stays in the team and who doesn’t. They can just give their feedback to the team members regarding performance and raise concern in case the team member isn’t performing well. A CEO, on the other hand, decides who stays in the organization and who doesn’t.

Apart from that, PMs do not decide on the budget and resources that are needed for certain initiatives. They generally receive them from upper management. And, they have to make things work in the ambit of those. Also, while they have the responsibility of steering the product towards success. They have no control over engineering, marketing or any other function. Product managers have to wade through various people challenges all by themselves.

Product management is not product marketing

It’s not a product manager’s job to worry about how the product will reach the market, what promotional strategies would make it a hit among users, or what should be the right pricing and messaging of the product in the market. While keeping an eye on the big picture is good, the product manager’s job should be more towards ensuring that the product they are making is technically robust and the team is progressing in the right direction.

One example could be- user research. Doing user research is more into the domain of product marketing rather than product management. Only a skilled marketing specialist would be able to deliver the right data points which can help make the product better.

The product manager can provide many valuable inputs like which web pages or CTAs should be tested, but it’s the job of the marketing team to conduct the research and pass on that knowledge to the product team.

Product management is not about delving into analytics

A common misconception is that the role of a product manager is to collect data and discover actionable insights from it. While the latter part is true, what people don’t understand is that the role of a product manager is to interpret the data, not collect it. PMs need to have an analytical eye which can work out what the product is lacking just by looking at numbers.

A product manager’s job is to decide which data should be collected and ask questions that can be answered through data. The “how to collect data” part should be left to data analytics experts.

So for example, the PM notices that people are dropping off from the checkout page? The PM would then ask data experts to fetch the session time, session duration, and exit pages. From that data, he/she would decide if they should change the page’s design or not.

Similarly, if the question is why there are no repeat visitors on the blog then PM would look at data points and say that probably the content isn’t engaging and we must research what our readers like to read.

I wouldn’t deny that a product manager needs to have a breadth of skills. But here’s the catch- Breadth, not depth.

The scope of product management is incredibly broad and varied and product managers have to be on their toes to run everything smoothly. They need to know what exactly needs their attention and how they can remove blockers for the team to perform well. But that doesn’t mean that product managers have to step in everywhere.

Product Management is about setting the vision of the product and aligning your team with it. Product Management requires you to do a lot of research- about your market, your users and the problem you’re trying to solve. Your job is to assimilate huge data inputs — be it feedback from clients, or data from Google analytics, research reports, market trends, and statistics — basically everything about your market and your customer.

I hope this blog helps you understand the difference between what product management is and what it’s not. And, gives you the strength to say no to things you shouldn’t be doing.

Happy product managing!

I wrote this blog for our Medium Publication- Unboxing Product Management. The publication is a weekly column by people of Quovantis to share their learning.

The Fallacy of Product Management was originally published in Unboxing Product Management on Medium, where people are continuing the conversation by highlighting and responding to this story.

Among the many definitions of product management, one that has stuck with me for years is this one- “product management is the intersection between the functions of business, technology, and user experience.”

This simplistic definition is given by Martin Eriksson who is the founder of ProductTank. Eriksson adds to this definition and writes that “a good product manager must be experienced in at least one, passionate about all three, and conversant with practitioners in all.”

Going by that definition, the life of a product manager is always caught up between discovering, planning and execution.

Needless to say, it’s a challenging job that requires product managers to hear everyone’s opinions, understand the bigger picture and weigh-in several aspects without getting influenced by their own biases.

Therefore, one thing is certain- there is a need for good decision-making skills. And that’s not an easy job. But for every challenging job, there is a weapon or an armory of weapons. So what is the weapon for product managers?

It is Mental Models.

What are the mental models?

The Wikipedia states — “A mental model is an explanation of someone’s thought process about how something works in the real world. It is a representation of the surrounding world, the relationships between its various parts and a person’s intuitive perception about his or her own acts and their consequences.”

In simple words, a mental model is a representation of how something works for someone as per their context. Just as thoughts flow freely, mental models take different forms in different contexts, depending upon the person’s understanding of the world.

For example- the mental model of a humanitarian varies dramatically from a misanthropist. While the former loves humankind and sees the world as a place to cooperate and collaborate, the latter dislikes it and avoids society.

So why mental models?

Mental models influence our thought process, how we view and understand things. They are thinking tools that help us to assimilate information, make associations and hence ‘judge’ opportunities that are presented to us. They help to train the brain to think in a way for a given problem. So mental models help us to simplify the complex entities into understandable chunks. And by virtue of doing so, mental models assist greatly in the tough job of decision making.

A popular analogy to mental models is that they are like tools in a toolbox. So, depending upon your need, you pick the tool to achieve the result efficiently and with speed. But to achieve efficiency one must-

1. Be aware of the tools that are available, and
2. Be proficient in using those tools.

There is a wide range of mental models that are used in different fields. For the scope of this blog, I will be discussing only a few that are relevant to the key aspects of product management — strategic decision making and understanding your team.

Another very important aspect of product development is UX which helps in understanding users and their pain points. But I’m not including it in this blog as it’s a wide subject in itself and needs careful deliberation. If you are interested in a wider study on mental models, I recommend these posts by Gabriel Weinberg and James Clear that have meticulous research from various fields.

Mental models that help in strategic decision making

Strategic decision making has several challenges as it requires answers to questions you can at the best ‘guess’ for the future.

“What is relevant today, will it be relevant tomorrow?”

“How long in the future do we plan for?”

“Is the solution local or global? Are we interested in global?”

When the focus of decision is on questions requiring a definitive outcome, then decision making will suffer from uncertainty and speculation. If instead, decision making is made process driven- a process of discovery — then one can leverage a few mental models to bring some science into the mix.

Two common mental models that can help to make decision making a ‘process of discovery’ are the Eisenhower Decision Matrix and the Law of inversion.

Eisenhower Decision matrix or Urgent-Important matrix helps you in prioritizing your tasks by grouping them into urgent and important quadrants. The idea behind this model is — you should be able to identify what urgency means exactly. Does it mean that the task should be completed today? If not, is it really a pressing matter that needs your attention today?

By helping determine which task belongs in which quadrant, the matrix helps to prioritize. And prioritization is the key to achieving things that need to be done by you today or later or to be entirely delegated to someone else.

The matrix is easy to use. Start with what needs your immediate attention; something which needs to be resolved immediately or at the latest, by the end of the day and has a high impact — put that in the ‘urgent and important’ quadrant. Similarly, if something is important to be achieved in the next few days, put it in the ‘important but not urgent’ quadrant. Rest follows easily.

While the Eisenhower matrix helps you to decide what to do, the Law of Inversion mental model is a powerful tool that helps you visualize what not to do in order to be successful. This mental model is based on the fact that if you know about things that can pull you down and if you figure out how to avoid them, then the chances of failure are bleak.

So, for example, if you want to decide the launch date of the product but are not too sure how it will impact your product’s success, ask yourself, “what could possibly happen if I launch my product in the market a little late?” By knowing the answer to the impact of not doing something now or 10 days later, you will be able to identify possible challenges and faultlines in your plan. Once you are aware of those, you can rework your strategy and timeline.

I would recommend you to read Ryan Holiday’s incredible book The Obstacle is the Way to better understand how the Inversion mental model makes things less complex.

Mental models to help you understand your team better

People form the backbone of any successful enterprise. Even if you are successful in the short term, if you don’t have the right people, you won’t thrive for long. That’s why it’s important that product managers make consistent efforts to understand each member of their team.

Mental models can be helpful in understanding people, their motivations, their potential, and their performance.

One of the important mental models that help product managers with people is an understanding of Emotional Intelligence. The importance of technology can tend to put the focus on IQ. But managers need to progress from IQ to EQ to help team members rise to their potential.

As, Daniel Goleman, the author who popularized EQ with his book, states, “For leaders, the first task in management has nothing to do with leading others; step one poses the challenge of knowing and managing oneself.”

Goleman outlines four EQ traits that help with motivations, impact, interactions, and collaboration.

1. Self-awareness — to understand and take control of your moods and emotions. When you are aware of your impulses and moods, you are better equipped to take control of them and its effect on your peers.
2. Self-management — to manage your own work without external help. It helps you see if your motivation is intrinsic or driven by external factors like bonus or appreciation.
3. Empathy — to understand what the other person is going through and treating them with compassion and care.
4. Social Skills — to help understand how you interact with your team and your ability to build relationships. It helps you see if you are a people person or not.

If you are wondering where you are on the EQ scale, this flowchart can help you find the answer.

There a few mental models on performance that challenge traditional concepts of improving performance.

The model Perverse incentives break the myths around monetized incentives to improve performance. It describes how such incentives can go awry, especially in situations where outcomes can be manipulated by people who have direct control over them.

To explain this, let’s take a common example of a financial incentive for those who would take the most number of training and certifications. The idea behind such an incentive could be to prepare the team for an upcoming project that needs a new skill. But the financial compensation as a motivator may not result in the desired outcome of people actually learning the skill. It’s possible that people might just do the training for the reward and not take the training seriously. As a result, on paper, it will appear that the team is prepared, but the reality would be different.

Another model that helps with performance and potential is the Peter Principle.

Created by Dr. Lawrence Peter, the principle states “In a hierarchy, every employee tends to rise to his level of incompetence”?

The model helps to detect early signs of stagnation, lack of motivation and fall in performance.

Consciously working with mental models can be a little overwhelming initially, especially if you are new to them. But like every tool, the more you practice, the better you can become. But there is also a paradox — since a mental model is a ‘viewpoint’, there’s a possibility that as you gain proficiency, it might block your worldview. So the best way to overcome such handicap is to continuously study more mental models and revise them against each other. Keeping an open mind is the best way forward.

I wrote this blog for our Medium Publication- Unboxing Product Management. The publication is a weekly column Quovantis to share their learning and knowledge with the world. If you liked reading the blog, clap your heart out and help others find it.

Mental models that make you a better product manager was originally published in Unboxing Product Management on Medium, where people are continuing the conversation by highlighting and responding to this story.

The hype around software as a service (SaaS) platforms has grown by multitudes and it wouldn’t be wrong to say that SaaS platforms are growing by leaps and bounds. Although, this hype is in a way beneficial and shows the successful adoption of a SaaS as a solution to many businesses. But it also uncovers another important facet of software development — successful deployment of SaaS products without any overflow of expectations, avoiding any misunderstandings and disillusionment regarding the scope of the product.

I have been a part of many development projects and I am aware of the ever growing customer expectations (with ever shrinking budgets and timelines). And with my years of experience I can say that every SaaS product needs a Cockpit.

Yes. A cockpit.

You’ve probably heard the word. It’s a common lexicon in the world of ships and aircrafts. Cockpits help pilots in monitoring the flight stats- they have flight data indicators, navigation displays, backup instruments and of course the pilot who steers the plane. Needless to say, it is as important as any of the core components of aircraft.

Bringing the analogy to software development, don’t you think we need something similar to a cockpit? You do not want your customers to say/feel any of these:

• We can’t access the application anymore. That’s a Crash!
• It is taking a lot of time today. Damn that turbulence.
• It is showing incorrect results. Gone nuts, have you?
• We are not able to acquire new clients easily. Failed take off!

To manage it well, you need to follow some of the essential and often overlooked services in your SaaS platform. Few of them are-

Configurability

Every user will use software to solve their unique needs. Although domain of their problems may be similar, but each will require little tweaks here and there. There will be small variations in business rules. For example, some customers will require two-factor authentication and some won’t. As a SaaS provider, you will require the ability to make those tweaks without any downtime. And, without affecting other customers unintentionally.

So, you need this ability in your cockpit to make these tweaks without reaching out to the engineering team to do it for you. Because the moment you have to make big changes in code to incorporate these tweaks for a particular client, two things that’ll cross your mind are- cost and delay in rolling out the changes.

Needless to say, both of these are not going to make your customers happy. As a product manager, you need to think of configurability all along. Don’t delay it till the time it becomes a necessity.

Another impact of lack of or limited configurability could be — your product will be in danger of being single tenant. Supporting multi-tenancy requires configurability at its heart. Kind of things that need to be configurable are — UI personalization, analyzing what an organization needs, customized rules processing, custom workflows, custom notification requirements, custom security needs etc.

Health monitoring and problem reporting

Typical SaaS applications aren’t social in nature. A lot of business needs depend upon them. They are critical for businesses. If something goes wrong, it’s going to affect their operations, make a lot of unhappy users and who knows how much of potential monetary loss. Therefore it is important to know the health of all your services all the time.

You would not want your users to come and tell you that a feature is not working as expected. Or it is down altogether. You would like the system itself to give vital clues if something is not right.

For example, if user login for a particular client used to take 500 ms, but it has been taking 800 ms since last 15 min, you would like your system administrators to know about it asap. Or, what if there have been more errors of a particular type reported in the system since a new roll out? The system should be capable enough to report and log such errors. For this to happen, you need to bake in required ability in your product. Fitting it in later, is not as easy as it may sound.

Licenses and quota management

Usually any kind of licensing model is postponed up until the last moment. But, by that time, it becomes very hard to implement. It’s better to keep an eye on possible licensing models right from the beginning. Chances are, you won’t be too much off from whatever kind of model you choose. Deviations will be easy to implement later rather than not having any.

Another aspect that is often totally missed is quota management. A very simplistic example of applying quota is — for a particular licensing model, how many transactions are allowed in a day.

If you are thinking why this is even important here is the reason — every transaction costs some money. Your profitability will be impacted if you do not control the per transaction cost. Also, this will help in planning your infrastructure needs. Based on quota that clients have opted for, your IT team will get an idea of how much hardware muscles need to be added and by when.

Auditing

The responsibility of data and what happens with that lies with the SaaS provider. Therefore, it is important to have robust auditing in place to track all the entity changes that happens in the system. At times it may be required to set up notifications on certain kind of events based on predefined thresholds.

For example if there are too many failed logins, system administrator may want to get an alert and also the ability to get details around those failed logins. For instance, from where they have been originated, what time etc. Auditing framework is very hard to add to the system later on.

This is one of those NFRs (non-functional requirements) that is often postponed to later stages. But the harsh truth is that stage never comes. As system grows, the cost of implementation of auditing grows exponentially. Sometimes compliance requirements enforce SaaS providers to setup auditing right from the word go. In other cases, it doesn’t. Whatever be the case, it is essential that auditing is built into the system right from beginning.

These are some of the essential NFRs that are must for every SaaS provider to consider early in the product life cycle. There are a few more– multi-tenancy, security, integrations, scalability etc. The ones mentioned in this article are most often overlooked.

Your system administrators, and to some extent administrators of each client, need a self-service portal to manage configurations, assess health of system, get alerts in case of problems and licenses. This self-service portal is your cockpit. Thinking of this cockpit early in the lifecycle of your product will help in baking the required support in the system for making this cockpit operational and helpful.

Hope this help you in building better products and sailing efficiently through your product management life cycle.

I wrote this blog for our Medium Publication- Unboxing Product Management. The publication is a weekly column by leaders of Quovantis to share their learning and knowledge with the world. If you liked reading the blog, clap your heart out and help others find it.

Your SaaS software needs a cockpit was originally published in Unboxing Product Management on Medium, where people are continuing the conversation by highlighting and responding to this story.

The most important single aspect of software development is to be clear about what you are trying to build. — Bjarne Stroustrup

The genesis of every new innovation is an idea which was laughable at first. It is only after the requirements are fleshed out, the idea starts to take shape of a software.

That’s why the very first step in any software development life cycle is gathering requirements. During this phase, the product owners state the expectations of the project including who are the intended users, how they have visualized the product to look/work or any other specific information that the team needs to know before the development starts.

If you look at the dictionary definition of requirements, it defines it like this- a thing that is needed or wanted. Quite apt! Why would anyone make something which is not wanted?

However, surprisingly, that’s what we struggle with software development these days. We are building things which nobody wants. We fall in love with dreamy requirements. Often, we misconstrue what the other person is trying to convey and build an altogether different product.

I found the below comic very appropriate in the context of gathering wrong requirements and building a product which is far far away from customer’s expectations-

I hope you get my point.

This problem is not new. Even during the waterfall days, requirement gathering phase was a puzzle for product owners and developers. It was one of the areas where painstaking efforts were needed to take care of the requirements. But alas! By the time the project was completed and came out in the market, it turned out to be nothing close to what users had wished for a few years ago. The cycle was endlessly annoying and the entire blame was put on ‘continuous change in requirements’.

This was the turning point when the Agile manifesto came as the Knight in shining armor and promised to ease out the pains software development.

But here’s the thing- whether it’s agile or waterfall, there are certain facets of requirements gathering that do not differ.

To ‘gather’ means to assemble or collect. In the context of software, it’s never as simple as it sounds. Requirements aren’t scattered all over the surface and we aren’t just supposed to pick them up. True requirements are rarely lying out there. Looking at you with hopeful eyes and saying to you- “I have been here for long. Why don’t you free me up from this wilderness? Get me into the code, please.”

It is much more complex than that. It’s equivalent to digging. The real requirements live in dark shadows. They lie deep under the surface and are hard to spot; hard to dig.

Why requirements are so hard?

“The greatest challenge to any thinker is stating the problem in a way that will allow a solution.”― Bertrand Russell

Requirements are hard because communication is usually hard. Look at it like this- if someone finds it hard to communicate their problems or if the person at other end finds it hard to understand what troubles the user, then there is no way in which we can arrive at a solution.

I am sure you have heard of Chinese whispers. The similar happens in software development. By the time, a requirement reaches developer, the metamorphosis has already happened. This is not the only challenge though. There are others as well. Like, changing business context, conflicting priorities, over-specification, under-specification, lack of empathy with users etc.

With my experience, I can say that lack of empathy for user’s problems and broken communication are two of the topmost reasons that make requirement gathering hard. And that is the reason why extensive digging is required.

Need inputs on how to do that? Below are my recommendations-

Know your users

“Know thy user, and YOU are not thy user.” — Arnie Lund

Users play a crucial role in the requirement gathering phase. It is they whose problems we intend to solve by building that product.

Can problems be understood without understanding the users? Absolutely no!

To know users, it is not only important to know their personas and their needs but to know why they have that particular need. In Agile, user stories cover this part in ‘so that …’ phrase.

Let’s take an example-

You need to build a store management software. One of the requirement is: As a supervisor, I should be able to add new employees to the system so that I can manage their on-boarding.

But is this the real requirement? This requirement shows no empathy to the supervisor. It may actually be adding a burden to his job. How many employees does she add in a day, week or a month? It could be anything from one employee to one hundred employees in a month.

What problems do supervisors face with on-boarding? How we as engineers can solve them? How can software enable the supervisor to do her work more efficiently? These are some of the very important questions which can only be answered when you spend time with your users and ask the right questions. If the situation permits, be with the users. See them doing tasks and note down the observations. This will go long way in setting the context for requirements coming in future. Know their motivations and pain points- try to seek answers to the five W’s (why, who, what, where, when) with just enough clarity.

If you empathize with the supervisor, the real requirement could be: As a supervisor, I need the system to help me in on-boarding new employees in the easiest and least time-consuming way so that I can focus on other things.

Even this is somewhat complicated. Why should supervisor be spending time filling all the details that the employee knows best? How about something like- as a supervisor, I should be able to generate a link for an employee which they can access to add their personal details. Later, their profile can be approved and activated after verification.

Simplicity always wins

In character, in manner, in style, in all things, the supreme excellence is simplicity. -Henry Wadsworth Longfellow

The moment requirements start becoming monstrous to implement, or to understand or stop making sense- it’s time to take a pause and breathe. Take a step back. Probably, the ship is sailing in the wrong direction. Probably, you had been working on the wrong idea all along. Try to go back and understand the context; the why. You can borrow Sakichi Toyoda “five whys” theory which is one of the ways to approach your ’why’.

As project implementation progresses far into the timeline, context is often lost. Which is why every requirement has to be contested and questioned if it brings complexity into the implementation. There could be simpler ways to do things and we might have overlooked them. So, try to think rationally and keep your solutions simple.

Save yourself from over-specification

Perfection is achieved, not when there is nothing left to add, but when there is nothing left to take away. -Antoine de St. Exupery

Going overboard with anything is usually worse than being under. It takes the focus away from the core of the problem and engulfs you in tiny details. I found an interesting blog which does the comparison between different styles of writing user requirements.

If not reviewed thoroughly, specifications may lead to cost overruns. There could be a simple ‘nice to have’ which do not provide much of the value to users. But will eat away the cost in the implementation. Another kind of over-specification could be elements of technical design in the requirements itself. It is better to keep requirements coarse and leave finer details to be discovered later. If you are seeing a lot of requirements churn, one of the reasons could be, you are specifying too much and too early.

Look beyond the functional requirements

There are two kinds of needs- one, which talks about ‘what’ the user wants to achieve. The other is ‘how’. What is typically about the features in the application. How tells about the experience in using the application.

Additionally, you must also identify requirements that aid in the usability of the application. Because if the application isn’t easy to use, responsive and resilient, users won’t be happy using it. Such requirements are called non-functional requirements.

Non-functional requirements (NFR) should be in focus all the time. Usually, most of the non-functional requirements are common across the application. They can be documented at one place and can be linked with other functional stories or features as applicable.

Do not ignore operational needs

This is one area that is usually missed. Especially during the starting phase of the project. It bites very hard in later phases. Once application gets traction and users start using it, there is pressure to release new features quickly. At the same time, the operations team is also getting formed. the operations team has support staff, administrators etc. Some of the functions they do include- handling user’s complaints, enabling on-boarding of new clients (if SaaS), monitoring the health of the application, managing deployments, data backup and archiving etc.

More often than not, when building products, these functions are never thought of. Resulting into the missing provision of these in the technical design. Then they will have to be retrofitted later on. And, retrofitting is way more costlier than it would have been if it had been done all along.

Keep an eye on business policies

To improve is to change; to be perfect is to change often. — Winston Churchill

Do not treat requirements as the Gospel of Truth. They all come with an expiry date. In today’s times, changes are happening faster than you can imagine. It is important to anticipate what could change and what could remain static.

Business rules are termed as policies. And changes often happen in business rules. So, it is important to dig policies out of the requirements and document them in a way that they are referenceable.

Also, policies should not be hardwired into the code. They should be kept separately from the code. The code should implement abstractions and not the policies. This way, it will be easy to implement ever-changing business rules and workflows without breaking the system every now and then. In their book — ‘Pragmatic Programmer — From Journeyman to Master’, Andrew Hunt and David Thomas have addressed the need and ways of metaprogramming at length. Metaprogramming is all about programming for the general case and putting specifics somewhere else.

Maintain a glossary

Communication has always been challenging. How often do you hear from your colleague, friend or your family member — “I never meant that”. It happens way too often. It happens so many a times that product owner or your peer meant something else and it is understood as something different.

For example, there could be a different meaning of ‘client’ and ‘customer’ in a project. Especially if it is a SaaS project. Not knowing the difference can lead to a lot of confusion. As your project evolves, new team members may join in. They won’t have the same context as old people in the team. It is always very helpful to maintain a project glossary where all the common terms used in the system are defined clearly. All the participants, product owner, engineers, support staff etc. can use a glossary to have a common understanding when collaborating on requirements or design or anything else.

I can’t stress enough on the importance of gathering right requirements if you want to build a product that conforms to the needs of the users. There are many techniques and methods which you can use to collect the right information.

I understand, all of this can get too overwhelming at first. But this step is critical if you want to develop a product which users love to use. Just make sure that you do not confuse requirements with design or architecture. Requirements are needs. And if you are able to capture this one right, you have conquered half the battle.

I wrote this blog for our Medium Publication- Unboxing Product Management. The publication is a weekly column by leaders of Quovantis to share their learning and knowledge with the world. If you liked reading the blog, clap your heart out and help others find it.

Solving the requirements puzzle was originally published in Unboxing Product Management on Medium, where people are continuing the conversation by highlighting and responding to this story.