Product improvement feature – Google Maps

Google touches the lives of so many people around the world everyday. That is what makes it the most successful companies. It is also one of the dream companies I want to work for not just for the compensation, the stock options, the lunch and their cozy offices but the awesome products and services this company gives to this world.

I do not trust any other search engines other than Google :). The first browser application I download and make it a default browser whenever I use a new computer is Google Chrome. No matter, what new paid tool is out there, nothing matches the collaborative power of Google docs and Google sheets, so-on and so forth. Enough of Google’s praise! Now, coming straight to the point of this article.

As an ardent public transport user, I have found one thing lacking in Google Maps which also is one of my favorite Google apps. I am from a generation which can appreciate the utility of Google Maps from the core bottom of my heart if something like that exists. This is not to exaggerate my age. I am in my thirties. Before Google Maps, I have struggled finding places, asking strangers, misled by strangers, yelled upon by strangers, gone round and round around the desired destination, etc.

One thing that stood to me as a useful feature that can be added to Google Maps, particularly the public transport directions is the stop that comes immediately before my desired destination. You may ask me how is that important than the destination itself. That is where I would like to emphasize the importance of user research and putting ourselves in the shoes of the user. The guided navigation probably has the feature where some machine voice will tell me that the next stop is where I must get down when I am on a bus or a train. However, I am not sure what percentage of bus or train riders would love to have a guided navigation for the entire stretch of their journey. It is important to know one stop before the actual destination because that is when I need to signal the driver that I need to get down at the next stop! This is a simple fact for any person who uses public transport regularly.

This is where I propose that Google create a visual hierarchy when displaying the public transport route and show the stop immediately before the desired destination without having to click and view all the stops.

Public Transport Route Directions in Google Maps

From a product management perspective, what is the lesson here? Empathy cannot stay on paper and in talks. User empathy is real and matters for product design. The best way to develop empathy is to simulate the conditions of the user as much as possible; a 100% if that is possible. In this case, a product designer from Google Maps could have taken a bus to the office daily for a week and would know what features really matter to the user. It is possible that this might have been done and yet, this need escaped! You can also perform what is known as Cognitive Task Analysis (CTA) with the actual users. I will elaborate more about CTA in another article!

Until then, good bye!

Will AI ‘transform’ the education like MOOCs did?

The year 2013 was a year of hype for MOOCs (Massive Online Open Courses) just like the year 2023 is a year of hype for AI (Artificial Intelligence). MOOCs were promoted as a panacea to all the ills that plague education. In a decade, we see that MOOCs have indeed brought a lot of benefits. It is now possible to attend quality lectures at your own disposal from the comforts of your home through applications like Coursera, YouTube, Udemy, etc. These lectures are from well known teachers from universities like Stanford and Wharton. Many learners including me could not even dream of such a thing. However, have the MOOCs ‘transformed’ education?

In my opinion, to say that MOOCs have transformed or will transform education is an overstatement just like many are overstating today that AI will transform education. Mistaking ‘means’ for the ‘end’ is not something new and the same is true here in these overstatements. Technology is a means to an end and not an end in itself. In the case of education, that end itself is not clearly articulated. There is disruption needed in defining that end.

I spent four years to get a bachelors degree in technology in electronics and had to study more than 40 subjects and pass more than 40 semester-end examinations to get that degree. I hardly use any of it in my professional life today. There is no sine(theta), no cos(theta), no civil engineering beams, no microwaves, no semiconductor chips, nothing. It seems like a waste of those four valuable years!

There are many foundational and essential questions that need deliberation and answering. These questions go beyond the technology aspects. These questions may be related to the philosophy of education, learning science, etc. Some of the questions that come to my mind in random order are:

• Do we really need academic degrees? If yes, who needs them and who does not?
• Should we teach nuclear physics to first graders?
• Is it worth to spend more than 50K USD and immerse yourself in a decade of debt payment to complete your higher education?
• Should civic sense, morality, and mindfulness be a part of school curriculum?
• In the era of skills explosion, what skills matter in what geographies from an employment perspective?
• Should education be a state subject and controlled by governments through departments of education?
• Can I learn a foreign language in a month just to communicate in everyday parlance by spending 4 hours every day on learning?
• Can we create a taxonomy of all employable skills?
• Can I attend an eLearning course and learn how to play cricket?

I have tried ChatGPT, Bard, Github Copilot and many other AI tools. I am really enamored by what these tools can do and have promoted them in my social media posts. I am however not convinced that these AI tools are a replacement for human beings. They may assist humans in various tasks and help us achieve things faster and efficiently but these tools cannot think like we humans do. There are many relevant questions that need answering. Idolizing a technology will in itself not ‘transform’ education.

Postscript:

As an Edtech entrepreneur and someone closely associated with educational technology, I understand the value of these AI tools. For example, transcribing content from one language to another is now much better handled by machines than it was some years ago. Even today, it still needs revision by a human being but the tool itself in its first pass helps a lot in reducing the time needed for final delivery of the content.

After I drafted those questions above, I also asked ChatGPT the following question.

Climate change and sustainability

There is so much to observe around us in our daily lives. There is also so much to learn from those observations. I was inspired to write this article because of two such observations.

I stay in Pittsburgh. The Port Authority here runs a world class public transit system. I have always hated owning a car and have been a fan of public transit though I now understand that having a car is taken for granted in the US. There are also some places that are just not accessible through public transit. The Port Authority runs a system of trains and buses. The vehicles are very well maintained, the drivers are very professional, courteous and punctual. In my more than two years of using this system, I have rarely experienced delays of more than five minutes with respect to the published schedules. What I noticed in many of the stations is that the escalators lack automatic sensors which are very standard nowadays. So, these escalators keep running even though there is none to use them. I believe that this is a huge waste of energy and small things like this, when corrected would help us live a sustainable life in harmony with this mother nature. We can also practice sustainable and minimalist living in our own lives and just ask or calculate if we are using disproportionate amounts of energy when compared to the per capita energy consumption in this world. I also just do not understand the concept of the yacht owning billionaires whose houses consume so much of energy that they could light many villages. Now, what did I do about this? I wrote to the Port Authority with a suggestion that they add sensors to these escalators. I hope that they will see merit in this suggestion and act on it.

I eat out very occasionally. In my last few visits to the restaurants, I have noticed people wasting so much food on the plates. I believe this is also not desirable as the food processing industry also uses a lot of energy and this is simply a waste. I believe it is not too hard to order just so much amount of food that one can eat and even if something is left over, one can always pack it and take home or feed some hungry souls. What did I do about this? I personally do not waste any of the food. In fact, the plate can go directly to the dish washer! I can also write articles like this with a hope that they will influence at least one soul.

January 12th is the birth day of the great saint Swami Vivekananda. This is the same person who won the hearts of millions around the world by his address to the World Parliament of Religions held at Chicago in 1893 starting with “Brothers and Sisters of America……”. India also celebrates this day as National Youth Day. I am constantly reminded of a quote of this saint.

So long as the millions live in hunger and ignorance, I hold every person a traitor who, having been educated at their expense, pays not the least heed to them!

Swami Vivekananda

User stories and acceptance criteria

Agile methodologies are light on documentation. In fact, one of the four agile manifesto items asks us to value working software over comprehensive documentation. This may not make sense to a lot of young product managers who have never seen the hefty pages of documentation that traditional software development lifecycle used. Sadly, this is still the practice in many organizations. Documentation per se is important provided it is created meaningfully as per the requirement in a quantity and has a meaning and a purpose. Documentation that is created as part of a ritual following generalized templates with irrelevant entries, etc. is toxic.

User stories are the kind of documentation that I like and is used in frameworks like scrum. A user story, as the name suggests, is the story of the user using the software a.k.a product. What is the user trying to achieve and why is what forms this terse documentation. It usually follows the format

As a USER, I want to —————–, so that ——————–.

The beauty of user stories is that it puts the user at the center of all development. Note that we are focusing on the WHAT and WHY. This is product management territory. HOW is where the development team comes in and defines how to achieve the what. Product manager or product owner writes these stories based on user research that may include qualitative and quantitative methods. Development team adds tasks that are needed for implementation and testing. This is how we truly make technology as a means towards an end.

The user stories are also organized into what are known as Epics. A group of stories is what forms an epic. This is helpful in organization. Just imagine all Tom and Jerry stories/episodes grouped into one group to distinguish them from The Flintstones! A prioritized product backlog provides direction to the product team in an organization. Development teams pull items from the top of the product backlog into the sprint. A sprint is a time duration of 2 weeks or 4 weeks during which the development team gives life to those stories. Again, this is where it becomes challenging in certain organizations where release management has a fixed process and release happens either at the level of features or stories. Feature is an intermediate hierarchy between story and epic. I am now digressing into the scrum framework. That is not the intention of this article.

Coming back to user stories, let me know concoct an example

As a job seeker, I want to upload my resume to the system and want the system to auto populate the fields required in the job application, so that I can use my time efficiently to fill many applications in a day.

This is where product management also becomes a sort of art and not a science. You can get creative in writing these user stories. How about

As a frustrated job seeker, I want to…….

Adding an adjective brings about the emotions associated with this feature for the user. So, a smart development team now tries to implement this feature to remove the frustration and not to add to it! Have you ever experienced this frustration when you upload your resume and all the fields are messed up for you to clean?

You cannot talk about user stories without talking about acceptance criteria. User story alone is a terse statement and does not provide the details that the development team needs. The user story only provides a high level context which is very important nevertheless. So, how do you add details. One way is to hit two aliens with one stone by writing well defined acceptance criteria. I really do not like hitting the innocent birds!

Acceptance criteria are usually written as a checklist and define what is the expected functionality when the user story is implemented. Let me try to create such acceptance criteria for our user story

• • The user interface must follow the visual design as per ADD THE PROTOTYPE LINK
  • Standard accessibility criteria as defined in THIS EPIC must be met (Link the accessibility link that has all user stories derived from WCAG guidelines)
  • The upload button must be inactive until a valid file is being uploaded from the user’s computer. A file is valid if it is less than or equal to 5MB and is either in PDF or .docx format
  • Once the upload starts, upload progress must be displayed in the modal as per the visual design
  • Once the upload completes, the upload progress modal must close automatically and the user must be on the first page of the job application with fields filled in automatically
  • Only those fields that can be extracted from the resume with a 100% certainty must be filled. Other fields must be left blank for the user to fill in.
  • Phone number must be formatted in a standard manner from the digits extracted from the resume.
  • So on and so forth

A product manager must check each of these criteria once the development and testing is complete. Unit testing and regression testing are common forms of testing that are used by the development team. Once the user story passes both the technical testing and the product manager is satisfied that it meets the acceptance criteria, the story is said to be done. In some instances, certain parts of the acceptance criteria may not be satisfactorily met and yet a decision may be made that it can be released and improved in a future sprint.

What is important for the product manager here is empathy. One must put oneself in the shoes of the user and write these user stories and acceptance criteria. You must use your insights from user research. Empathy is easier said than done because of the prejudices that we carry with us. With practice, such prejudices and assumptions can be minimized focusing purely on the different persona users in question.

Beyond tech debt towards product debt

Technical debt is a term popularized in software development that refers to the implied cost of additional rework caused by choosing an easy fix in the present instead of using a better approach which may take more resources (time and money). Things are never ideal because organizations do not sit on an infinite supply of time and money. Just like in our lives, having debt is not a sin in itself. Not being aware of the debt and allowing that debt to spread beyond sustainable limits is!

The intention of this article is not to talk about tech debt or ways of managing tech debt. I am writing this article because I have felt the need for a term like ‘product debt’. Maybe, it exists and I just do not know. In my experience too, I have seen just technology debt and not product debt in the product roadmaps. One organization that I worked also had a dedicated team for managing technology debt. I believe that debt should never reach an extent that you need a dedicated team to handle it.

I always like to see technology as a means to an end and not an end in itself. Again, means is an important as an end and in some cases like machine learning algorithms that spit out ‘Movies that we think you may like’, means i.e. the algorithm at play has an important role to play towards the end i.e. the recommendation. Debt that accumulates for a product can extend beyond technology. There can be design debt. Again, Wikipedia uses design debt as a synonym for technology debt. I do not think that is right. Are design and technology synonymous? Maybe, yes, for people who feel that the world is full of Java, Javascript, Python, APIs, etc.

During the design thinking phase or the design sprint phase, the team could have chosen a sub optimal solution for want of time, money or for some other reason. And, when I say solution, I just do not mean the technology. In fact, design phases do not go deep into the technology aspects of how the problem will be solved. Choosing a sub optimal solution today must also mean that there is scope for improvement. This is where the concept of product debt comes in. Such solutions or features can be tagged in the product backlog as product debt. They can be taken up as part of the product roadmap conditionally based on certain conditions being met like those of revenue or profit goals. When you start earning more, you just do not party all that money or go to Las Vegas! You also try to repay some of our debt. There can other forms of debt associated with a product. Missing documentation or quality of product documentation is also a concern. Brand consistency may be lacking. Even that is a debt. So, it is important to note that product debt is more than technology debt and one must keep track of such debt and dispose off such debt if the product and the organization are to sustain in the market.

In fact, I believe that if product debt is managed, then a product can be ‘immortal’. There will probably be no need for ‘sunsetting’ a product.

As a side note, I also like to relate this debt business to my daily life when I am cooking something. I like to keep my kitchen table clean when I am cooking and I do not wait until all the cooking is over. I use breaks in between cooking steps to do dishes, keep cleaning what is being dirtied, etc. So, if we think of our product as a kitchen table that we want to keep clean, just be determined to use your time and other resources judiciously to clean that debt whenever you can! The product will stay clean.

Design – an overloaded term in product management

Merriam-Webster’s online dictionary provides the following as the essential meaning of the word design

1. to plan and make decisions about
2. to plan and make something for a specific use or purpose
3. to think of; to plan in your mind

When people talk about ‘design’ in product management, most of them, in my experience refer to visual or interaction design. They refer to the look good, feel good aspect of the web application, mobile application or a physical product. But, design is more than that. The company Ideo has already popularized the concept of design thinking. Google uses design sprints in its product development process. Design sprints follow six phases: Understand, Define, Sketch, Decide, Prototype and Validate.

Understanding the problem to solve, the users for whom the problem is being solved, the different ways in which the problem can be solved and then implementing a prototype, testing the prototype with the user to assess how well the problem in hand was solved are all aspects of design thinking.

Design, in general is more than background colors, avatars, buttons and drop down menus. It is the way you solve the problem. Technology and UI components are a means to an end. It is essential for product leaders to recognize this. I have seen organizations creating design as a separate entity within an organization and delegating all ‘design’ tasks to that entity. This is not the right approach according to me. An eye for design and understanding of best practices of wholesome design must be imbibed into the entire product team. All goals, be it technology, visual design, marketing, or sales must connect with the product goals as a two way street. The product goals themselves must connect with the organization goals as a two way street. An organization and its brand is nothing but the product or service itself. In fact, it so happens that many a times, the name of the product or services is more popular than the name of the parent company.

There are some people who are more creative when it comes to visual design, interaction design, etc. Such talent can always be included in product teams as product teams in agile are self-organizing teams. But, creating silos within organization for design will impact the product negatively as there will then be ‘more chefs in the kitchen’. On my reading list for 2022 is this book titled ‘Creative Confidence‘ by Tom Kelley and David Kelly. Hopefully, I was very good at painting and drawing in my school days. Somehow, I did not nurture that skill in the long run. And again, design is more than painting and drawing. But, it is this aspect of visual design that I want to add to my skill set: knowledge of colors, typography, interactions, etc. There are tools like Adobe XD, Figma, etc. that I want to use to unleash my creative potential as far as visual design is concerned. As for the rest, I believe I already have a good handle on design thinking, an eye for visual and interaction design, etc.

Also, the next time you speak about design in your conversations with you team, make sure you qualify it enough so that the other person or persons understand what aspect of design you are talking about!

How I interview and like to be interviewed

A decade has passed and I have experienced hundreds of interviews, some as an interviewer and some as an interviewee. There are both pleasant and horrific memories!

A basic understanding of English allows one to interpret the literal meaning of interview. It is a mutual exchange of views. It all starts with a shoddy copy paste job description from a template job description for product manager, a template job description for full stack developer, a template job description for data scientist, so-on and so forth. This is already a step gone wrong. Then, there are some hiring managers who put their heart and mind in creating a job description that clearly states the specific requirements for that role. This role requirement does not happen in a silo. The hiring is happening for a purpose. The hired person will have to play a role and contribute to a particular part or all parts of the product roadmap, if you are hiring for a product manager. What is the emphasis that you must provide on leadership skills if the role has ten members reporting versus none reporting (individual contributor)?

Once the job description is out, candidates are being sourced through various channels. There will be some lucky folks whose resume will be blessed by the almighty ATS (Applicant Tracking System). The human resources team usually does a first round of screening and then surfaces only certain high potential candidates to the hiring manager. The hiring manager now selects some for the interview.

This article is about what I feel are best practices for the interview.

Be on time. This applies both to the interviewer and the interviewee. As an interviewee, I have always made it a point to be four to five minutes earlier in the virtual meeting room. For an on site interview, this depends on the distance between your location and the office location, transport options, etc. Again, being an interviewer does not place one on a high pedestal. The interviewer must also be on time.

Things happen. For some reason, if one cannot make it to the interview on time, reach out to the other person and inform. The other person will understand and if he or she does not, then probably there is already a misfit.

A humane interviewer will make the interviewee comfortable with a smile, uses a soft tone of voice, greets with a greeting, engages in some informal talk about the weather or some other event, etc. Note that the interviewer was also an interviewee at some point of time in his or her career.

I hate the first question to be ‘Tell me about yourself’. You have gone through my resume and you already know a bit about me. The interviewer must make some efforts to first lay down the expectations about the structure of the interview and ideally the time limits also, because interviews are time boxed events. Once the structure is laid down, it is also a nice courtesy to ask if it sounds good for the interviewee and if the interviewee has any questions.

I usually like the following structure in general. There can be exceptions

• Reiterate the job description
• Add some context about why this hiring is taking place
• Pick questions that intersect between the skills mentioned in the resume and what is needed by the role
• Ask scenario based questions; follow up with what-if questions if relevant and needed
• Assess team player personality and personality in general
• Try to add some discomfort and see how the interviewee responds
• Provide logistic information like range of compensation, work culture, relocation, etc.
• Provide a timeline for next steps – what can be expected by when

Questions can start with something like ‘I see that you have this skill or this accomplishment’. Can you tell me more about that? Once you get an answer, you can then add something from the role expectation. This role requires this skill in this context. What will you do when you are faced with this situation? Throw in a scenario. You can see how the conversation can seamlessly flow from a statement in the resume to a scenario.

I also have come across many situations as an interviewee when out of the blue, the interviewer asks the question ‘Tell me about a time……’. I hate these kind of questions and have made up my mind that I will humbly ask the interviewer not to ask such questions. As part of interview preparation, I can make some notes and prepare for such questions in advance. Add some exaggerated statements, etc. But, does one need to ‘prepare’ for an interview? You can revise some concepts, brush up some of your knowledge, etc. The problem with ‘Tell me about a time….’ for me is that it is difficult to recollect details and this already kind of diverts my focus and energy on recollecting. The interview is already de-railed. Also, I cannot divulge details that are necessary to give enough meaning by virtue of some ethical considerations about previous employers, non disclosure agreements, severance agreements, intellectual property protection agreements, etc.

I like scenario based questions the most as there is a genuine attempt to simulate the conditions at work and assess the interviewee’s response. There can also be other kinds of hands on assessments. In one of my interviews, I was being given a scenario and asked to write a user story and acceptance criteria. As an interviewee, one must always ask questions if the scenario does not provide enough information. This can also be a stealth assessment that the interviewer can plan by not providing some information on purpose. The expectation here is the interviewee will ask relevant questions needed to complete the task.

In the end, exchange greetings. Thank each other and hope that the interviewer or someone gets back to you either with a positive or a negative response. For me, it does not hurt as much when the result is negative as when there is no response. No response is a response only on dating sites!

I have had some horrific experiences where interviewers with big titles and very high academic credentials mentioned that they will get back by so and so date and never got back. I am now mentally prepared that some people usually do not mean what they say. Pray that you did not end up in such an organization where communication courtesies are at such a low and carry on with your life.

Whether you are an interviewee or an interviewer, please note one thing. Be a good human being! Jobs come and go. Being nice does not cost much.

‘Commander’s Intent’ for Product Leadership

Organizations may call themselves matrix type. They may say that employees can directly communicate with the CEO, etc. I have realized this is more of a myth than a fact. I am not sure why people say things that they do not mean! Hierarchical organizations somehow gained a negative connotation and it became fashionable for organizations to call themselves matrix type. The truth is that hierarchy does exist. Imagine an organization where everyone in the ‘matrix’ draws the same salary!

I do not want to harp on the structure of organizations in this article. The reason I bring hierarchy in this discussion is for some other purpose. Every organization, every product, every project, etc. require a vision. This vision is usually set at the higher levels of the hierarchy. The organization could have used a bottom-up approach to collect feedback from the lower levels or the ‘Highest Paid Person’s Opinion (HIPPO)’ might have prevailed and the vision might have been set just by a few at the top of the hierarchy.

However the vision is set, it is of no use unless it is internalized throughout the organization. For the purpose of this article, I mean product vision when I speak about vision. Ideally, the product vision must lead to an outcomes based product roadmap, which can then further be broken down even to the task level for tracking purposes. Say that an educational technology company has set a product vision for year 2022 that it will make its learning applications interoperable with the learning management systems as per the latest interoperability standards. Now, the entire cross functional teams involved in designing, launching and maintaining these learning applications must internalize this vision into everything they do.

This is where I would like to introduce the concept of ‘Commander’s Intent’. This is borrowed from the U.S Army. I was first introduced to this concept when I read the wonderful book titled ‘Made to Stick‘ by Dan and Chip Heath. I will be writing more about parts of this book in future articles. Plans and vision statements are useful to think through the right issues and set a direction but the Army has realized long back that ‘They just don’t work on the battlefield’. So, in 1980s, the Army invented this concept called ‘Commander’s Intent (CI)’.

CI is a plain statement that appears at the top of every order. It mentions the plan’s goal and the desired end-state of the operation. The beauty of this is that the CI never adds so much details that it becomes obsolete in the face of unpredictable events.

The example that is mentioned in the book by Dan and Chip Heath by a colonel is the following:

At high levels, the CI may be relatively abstract: 'Break the will of the enemy in the Southeast region'.

At the tactical level, for colonels and captains, it is much more concrete: 'My intent is to have Third Battalion on Hill 4305, to have the hill cleared of the enemy, with only ineffective remnants remaining, so we can protect the flank of Third Brigade as they pass through the lines.'

By now, I hope you appreciate the utility of CI and relate it to how product leaders can trickle down the product vision in an organization. What is important is the intent and the details need to be set autonomously at each level of the hierarchy. In our ed tech example, the high level intent was to make the learning offerings interoperable with the learning management systems as per the latest interoperability standards. This at the tactical level of a product manager, managing a product team could be something like ‘My intent is make all our single choice correct multiple choice questions compliant with Question and Test Interoperability (QTI) specification V3.0 defined by IMS Global by the end of this quarter’.

I have seen product leaders across the entire spectrum of quality. Some giggling their time away with no ounce of product mindset and some micromanaging to the extent that they need a particular font type and color! I personally feel that the concept of Commander’s Intent serves the purpose of trickling down the product vision from top to bottom, providing autonomy for all levels to add enough details that are need to make the intent a reality.

I hope you learnt something new from this article. I also want to experiment if this hierarchy of ‘Commander’s Intent’ itself can serve as product roadmap!

You can learn more about CI here straight from the horse’s mouth.

I will see you in another article!

Feature Toggles

In this article, I will explain the concept of feature toggles as I have understood and practiced them. Feature toggles, also referred to as feature flags or switches sometimes is a technique employed in software development to provide alternate paths without needing to maintain multiple branches in source code.

There are many uses cases and advantages of feature toggles. I have not been fortunate enough to experience all those use cases in my experience so far. I will delve into those that I have experienced and those that I have not but are fascinating to me.

Feature flags are essentially variables used inside conditional statements, enabling the blocks inside the conditional statements to be ‘toggled’ on or off depending on the flag. Imagine a scenario where a regulatory compliance requires your team to make some changes in the payment process when using internet banking in the next two months. There is a hard deadline for this compliance. If the team needs around two weeks to make these changes, then you are ready to release this change. But, payment is a critical feature that you may not want to disturb. This is where a feature toggle can be useful. You can create a toggle that will essentially allow some internal users to test the new payment process in production. This allows you to test a crucial feature like payment in production without disturbing the actual payment process for the thousands or millions of users who may be using the payment feature.

Feature flags are also used to perform a canary release. These are releases where a new feature is turned on for a small percentage of user base. One of the literal meaning of canary is an informer or a decoy for police. The ‘canary’ users provide useful feedback on the feature and thus the name canary.

As a product manager, this is where your mind must immediately trigger the concept of A/B testing. If a small set of users can experience a different user flow, can we somehow route users to two different user flows in run time and create an A/B experiment with a random sample. Yes, we can, using feature toggles. You can add sophistication and also implement a stratified random sampling if you have or can derive the necessary metadata for the users. Now, A/B testing for carousel images, button locations, marketing copy, etc. do not pique my interest so much as A/B testing a complete user flow with changes that may help us evaluate features in a systematic way. This is where feature toggles can be helpful and this is what fascinates me. I have not had the fortune of working for an organization that is wiling to do A/B experiments at this scale. There are also ethical considerations of A/B testing that one must keep in mind, particularly if the experiment is in domains like educational technology, where the learning children are the subjects of the experiment. I will write an article on those considerations in another article.

Another useful category of toggles are the release toggles. When feature flags are used as part of the continuous delivery framework, they allow in-progress and in-review features to be checked into the master while still allowing that branch to be deployed to production at any time. I believe this is how companies like Spotify release ‘hidden’ features that are released before they are completely developed to identify integration issues earlier. In some cases, the feature may be complete but the team may be waiting for an opportune time to match something like a marketing campaign or a seasonal event.

I have also heard about operation toggles where feature flags are used as a kind of load balancer to degrade non-vital system functionality. Imagine a prime day sale and a feature of the e-commerce website that has zero relevance to the prime day sale.

All this may sound cozy and exciting. It is, if used in the right manner. The usefulness of toggles can be shadowed by non-standard practices of creating toggles and creating what is known as toggle debt. In some organizations that I have worked for, toggles are spread out through the codebase like ‘land mines’ with no relevant comments, no feature to decommission the toggle in the product backlog, etc. Toggles may be used for short-term or long-term but not forever and this is something important from a product manager or a product owner’s perspective. I like to call it something like ‘the law of opposites’. Whenever you create a feature in your product backlog to create a feature toggle, also create a counter feature to remove the toggle, even if that needs to be removed after a year. This way, you or a future product manager will have visibility of the presence of that toggle and the need to retire that toggle at a later date.

If you are interested in more details about best practices of implementing feature toggles from a technical perspective, I highly recommend Pete Hodgson’s article on the same, available at https://martinfowler.com/articles/feature-toggles.html

I hope that this article provided some useful information, at least to some of the readers.

See you in a future article!

Minimum Desirable Agile in a Scrum Framework

Agile nowadays is a fashionable term just like artificial intelligence and machine learning. Every organization wants to use these words to describe themselves or their products. But, can an organization become agile just because it describes itself as agile? I don’t think so!

Being a certified scrum master myself and having been a part of the product development lifecycle as a product manager and product owner, I have seen various flavors of agile. It all begins with ‘we have our own agile processes’, whenever I have started working for an organization.

While it is perfectly fine to customize the agile processes as per the needs of an organization, I think there are certain minimum considerations for an organization to label its product development lifecycle as agile. In fact, agile frameworks like scrum allow for that flexibility, unlike the traditional project management body of knowledge, where inputs, outputs, processes, templates, etc. are being defined in a straitjacketed manner.

The way I have understood agile is by imagining an athlete on a track. Even the terms like sprints used in scrum help me associate with this imagination of an athlete. Being agile is to be flexible in terms of requirements planning and the phases itself. It is about constant adaptation to meet the goals. One of the common goal is to optimize value, however that value is defined and to deliver that value incrementally. So, this athlete a.k.a. the organization develops a stamina to win races and attain business goals over time.

I consider the following as absolute minimum requirements in terms of understanding and practice for the product development lifecycle to be called ‘agile’ in a scrum framework.

First of all, the three pillars of scrum must be known to everyone on the team. They are the basis and form the core ideas of the scrum framework.

1. Transparency: Significant aspects of the process must be visible to all stakeholders including the development team.
2. Inspection: scrum artifacts and progress towards a sprint goal must be inspected with a regular cadency within the sprint to detect undesirable variances and course correct.
3. Adaptation: This is the course correction part where aspects of the process and its results that are outside acceptable limits are adjusted.

Secondly, the following roles are needed. It is not enough just to have these roles but the people in these roles should also be capable of performing the basic tasks associated with these roles

1. Scrum master:
   1. Coaches the team
   2. Removes impediments
   3. Facilitates scrum events
2. Product Owner
   1. Expresses product backlog items
   2. Orders the product backlog to best achieve goals
   3. Ensures that the product backlog is visible, transparent and clear to all
   4. Ensures the the development team understands product backlog items
3. Development team
   1. Is responsible for the ‘done’ increment
   2. Creates sprint backlog
   3. Sizes and estimates work

Note that the same person may be performing more than one role, particularly in startups. It is not uncommon for the product owner to also discharge the responsibilities of a scrum master. However, the person must understand the responsibilities of the roles and must be capable and able to execute those responsibilities.

Thirdly, the following scrum artifacts are required. These artifacts either feed into a scrum event or are an output of a scrum event.

1. Product backlog: It is an ordered list of features, functions, requirements, enhancements and fixes. Each of these will have a description, an order of priority, an estimate and the value they deliver.
2. Sprint backlog: This is a list of items that the development team pulls from the ordered product backlog. In fact, the adjective ‘ordered’ is a misnomer because product backlogs are supposed to be always ordered.
3. Potentially releasable product increment: This is an incremental feature, function, enhancement or a fix that is delivered by the development team at the end of each sprint. Ideally, this will match the sprint goal that was decided as part of the sprint planning. Potentially releasable means that the increment in question has been reviewed, tested and documented.

Lastly, the following scrum events, when meaningfully held add a lot of value and bring life to this whole process.

1. Product backlog refinement: The product owner is responsible to keep the product backlog refined. This means that all items that have been identified must have a place in the product backlog with their respective description, order, estimate and value. Again, some of these will be added in an evolutionary manner. Note that this is an ongoing process unlike the events below which follow a cadence.
2. Sprint planning: A sprint is a time box of one month or less during which a potentially releasable product increment is created. Sprint planning is the event where the team gathers together to pull items from the product backlog, brainstorms the product backlog items and creates a sprint backlog and an overarching sprint goal/s. To do this, the development team will also decompose the functionality to be done into smaller level tasks so that appropriate estimation can be done. This event is time boxed for 8 hours for a 1 month sprint.
3. Daily scrum: These are also known as daily stand up. This is an event that takes place in the same place at the same time every working day. This event is time boxed for 15 minutes per day. Note that this is an accountability session where team members are made accountable for their time. Gone are those days of ‘Taylorian’ methods. The main objective of this even is to inspect progress. The three questions that every member answers are
   1. What did I do yesterday that helped the development team meet the sprint goal?
   2. What will I do today to help the development team meet the sprint goal?
   3. Do I see any impediments that prevents me or the development team from meeting the sprint goal?
4. Sprint review: This is an informal event where the scrum team showcases working product and collects feedback. The stakeholders help resolve impediments and provide feedback. This event is time boxed for 4 hours for a 1 month sprint.
5. Sprint retrospective: The objective of this event is to inspect and adapt the scrum itself for continuous improvement. As the name itself suggests, the team retrospects to find out what went well, what did not go so well and what can be done to improve in the upcoming sprints. This event is time boxed for 3 hours for a 1 month sprint.

So, these 3 pillars, 3 roles, 3 artifacts and 5 events form the core structure of a scrum framework, which is a popular agile framework in action today.

I hope that this article gave you a bird’s eye view of the scrum framework. I will zoom in and provide more details, while also adding my own experiences about scrum in future articles.

Until then, good bye!