Modern businesses have disrupted traditional industries by leveraging technology and have created new standards of excellence. They’ve paved the way for new business models to deliver better value to customers and to a larger scale of customers than ever before. Netflix killed the cable TV business. Amazon transformed our shopping experience. Fitbit brought personal health to the forefront. They've created products that are in the hands of millions of people across the world.

Disruption of this magnitude is possible only by intersecting a strong engineering culture with a product strategy that is driven by customer insights. Today, stand-alone products are passè - platforms form a crucial foundation for an ecosystem of consumers, merchants and service providers. They enable businesses to reach a larger customer base, and shake up the industry. 

We relate the story of a true digital disruptor - an organization that chose to focus on turning the insurance industry on its head and changing how people think about their personal health. This is a story of ups and downs, of experiments and learning, of technical excellence and user-centric focus. Follow along with us, from once-upon-a-time-an-idea-was-born all the way through to the-users-lived-healthily-ever-after, in this story of how technology overhauled a traditional industry forever.

What if we narrate 3 anecdotes about unconventional means to create happy engineers?

Story #1 - How a product owner made the engineers happy by articulating their customers' extra sleep due to the team's work?

Story #2 - How did a 'rewards committee'  come up with a reward for a winner of an in-house contest, with a budget of 0 INR?

Story #3 - How did a 'product team' take on the adventure of killing the mutant invaders using JavaScript while saving money for the organization?

Businesses are building digital platforms with modern architecture principles like domain driven design,  microservice based, and event-driven. These platforms are getting ever so modular, flexible and complex.

While they are built with architecture principles like - loose coupling, individually scaling, plug-and-play components; regulations and security considerations on data - complexity leads to many unknown and grey areas in the entire architecture. Details on how the different components of this complex architecture interact with each other are lost. Generating insights becomes multi-teams, multi-staged activity and hence multi-days activity. 

Multiple users and stakeholders of the platform want different and timely insights to take both corrective and preventive actions.Business teams want to know how business is doing in every corner of the country near real time at a zipcode granularity. Tech teams want to correlate flow changes with system health including that of downstream stability as it happens.Knowing these details also helps in providing the feedback to the platform itself, to make it more efficient and also to the underlying business process.

In this talk we intend to share how we made all the business and technical insights of a complicated platform available in realtime with limited incremental effort and constant validation of the ideas and slices with business teams. Since the client was a Banking client, we will also touch base handling of financial data in a secure way and still enabling insights for a large group of stakeholders.

We kept the self-service aspect at the center of our solution - to accommodate increasing components in the source platform, evolving requirements, even to support new platforms altogether. Configurability and Scalability were key here, it was important that all the data that was collected from the source platform was discoverable and presentable. This also led to evolving the solution in lines of domain data products, where the data is generated and consumed by those who understand it the best.

Whenever we talk about automation we generally limit ourselves to tests (Be them Unit, Integration, or End to End).

Yet, We spend a considerable amount of time on Test Data Creation (Unknowingly and Unwillingly) during many other Day to Day activities.

In this talk, I will demonstrate different tools along with one open-source tool "Corr" (that I made) to write test data as code. One can parameterize, randomize, correlate data creation steps in this code and each code snippet can be directly run from the IDE plugin that supports this data creation code language.

Are you a frustrated developer who feels like they know enough? However, the success you thought you would have is out of reach. You see others who make better strides but why? Is it a skills gap? Come learn how to set yourself apart as a developer and learn the skills of influence and collaboration.

While we see disruption happening everywhere and the world is experiencing unforeseen crisis, many organizations are not able to respond quickly to these situations. One of the primary reason is their current workforce is not ready for it.
In this session, I will share my experiences of how some of the organizations we have worked with,  have built the digital workforce and nurturing such talent to take on these challenges, embrace change and move fast.
The areas that I will cover in this session are around building digital talent portfolio, hiring for culture, building the learning organization and scaling the workforce in a non linear way.

If you have witnessed enough Agile transformations, you have probably experienced a plateau in the journey; or worse, you have experienced “the great dip”.

Agile Transformations frequently start with a lot of fanfare, see a fast-paced adoption laced with early successes, and then settle into a plateau where we experience little to no improvement OR begin a slow, painful slide into a trough where behaviors start regressing to old ways.

What keeps us stuck on the plateau of change? What might drag us into this great dip?

There are the usual suspects – management has found the next shiny object, coaches and transformation agents only know how to help us get this far, all the easy stuff is done, the frozen middle (management) never really unthawed and so on.

People with a lot of experience in helping with transformations will know to watch out for these and would have developed ways to navigate these obstacles – we know what they look like and we have developed a reliable range of responses to them.

What really blindsides us are the watermelons! Stuff that looks green on the outside but is a dangerous shade of red on the inside. Surprising traits that are superficially positive but can real drag a transformation effort down.

Through this talk I will draw upon my experience of over a decade in Transformation roles to share what these Watermelons are, telltale signs that these are lurking in your system  and ideas to tackle them.

Agile transformations happen in a particular context, with two very critical parameters. One is the orientation of the coach who is guiding the transformation. The second is the leaders - who are key stakeholders and decision-makers in the organization transforming. Programs often observe differing results based on these parameters. This model which is a conceptual one attempts to capture the same and looks at the influence of those parameters and possible outcomes. Based on the coach and leader dispositions, the outcomes could range from conflict, checklist agile, or other antipatterns. This model is a thinking tool that can be leveraged by participants to provide insights into and ponder on the state of their agile transformations and how they can move towards better transformation outcomes.

The session will orient the participants towards this model with real-world examples from large-scale implementations.

Design thinking is fundamentally important to product innovation. It is perhaps to product-market fit what the compass and the sextant were to ocean navigation in the age of sail.  Yet as software keeps on eating the world and enterprises face a risk of obsolescence and disintermediation, is design thinking enough to keep disruption at bay? Is it enough for enterprises to focus obsessively on their users? Or is such focus - so vital to every startup - too limited and too limiting, when it comes to driving solutions to Enterprise scale disruption?

We believe that preempting or countering disruption requires supplementing design thinking with Ecosystem thinking. We believe Ecosystem thinking is a distinctive approach, that is far better aligned to the skill profile of large enterprises. Yet it is poorly understood and poorly practiced (if at all).

The purpose of this talk is to create awareness of Ecosystem thinking as a distinctive approach that should the primary sensible default at an Enterprise scale. Given the relative unfamiliarity of many of its key tenets, the goal is to not to overburden the audience with excessive theory about Ecosystem thinking but to have an engaging session that showcases ecosystem thinking in action, centred around the history of the innovation of the typewriter and the establishment of QWERTY as the default standard for typewriters. While the example is somewhat anachronistic, it is intentionally so. The goal is to demonstrate that the core concepts of Ecosystem thinking have lasting applicability and that Ecosystem thinking is a natural successor to concepts like strategic power and game theory that are well established in business strategy but poorly integrated into product innovation frameworks like design thinking.

What is Ecosystem thinking? How different is it from product or platform thinking? Why should Enterprises redesign their innovation playbooks based on Ecosystem thinking? These are some of the questions that the talk will look to trigger.

The usual suspects in change management models plot a familiar curve when describing the impact of change on individuals, teams or enterprises as a whole. When a change is implemented, at first there is a “dip”; in knowledge, in competence, in confidence, in emotional state, in cooperation, in performance. Organisations and their people go through a decline before moving on to realise the desired benefits of the changes they are implementing. But what if we could accelerate the learning and smooth out this "productivity dip"?

The traditional change management discipline seeks to address this issue but the approach is hampered by being inherently linear in nature, having grown up supporting traditional linear program management practices. The more complex an organisation’s change portfolio is, the more the traditional linear approach to change management isn’t going to cut it. As contemporary organisations focus more on enterprise level business agility, opportunities arise for the change management discipline to move away from the fixed time, cost and scope criteria of linear change management, towards an agile organisational change management strategy underpinned by continuous engagement, regular feedback loops and the ability to pivot in response to feedback and changes to market conditions.

The terminology of ‘productivity dip’ or even ‘performance dip’ comes with connotations of activity-based measures and have a way of anchoring the change process into a linear predefined ‘push’ of information. Mia will explore that by re-framing ‘productivity’ as ‘value delivery’, the outcome and impact on people is brought back into focus in the change portfolio. Ultimately, an agile change management approach will help you to build a change program that truly welcomes changing requirements.

Mia will show how Agile change management returns the customer to centre stage. In the context of agile product management rolling out smaller changes more often, agile change management activities can start to genuinely deliver their change management outcomes as intended to decrease the depth and duration of the dip. The change curves modelled for individuals, teams and organisations remain relevant, but each step will be small, anticipated, and normalised. This session will explore how to use Agile Change Management approaches to ensure that business readiness is part of each iteration rather than something that is done later downstream. This means that the productivity dip of the traditional change curve becomes downsized into insignificance in a sustainable ongoing improvement journey founded on the small incremental iterations of evidence-based inspection and adaptation.

How do you introduce yourself at a conference or any event? Your name, your designation, your years of experience probably. How many of the new people whom you have met for the 1st time at conferences do you remember, a handful? Probably none? 

The regular formal introductions don't excite the human brain. In events I have met people who spoke about having horses as pets or people who brew their own beer and I remember them very clearly and attach a memory/rather recall a memory as soon as I bump into them somewhere, versus the people who gave some professional designation, year based introduction etc. 

Human brain works in exciting ways, if I have to explain it with Pixar’s ‘Inside Out’ analogy then it's the personal touch which helps create more memories compared to the dry professional summaries. And this personal touch is the core of the ‘Personal Introduction’ Manifesto. 

While 1. The organization you work at, 2. Educational Background, 3. Designation, 4. Work experience history is important while introducing yourself to someone. We should give more importance to our 1. Geographical origin, 2. Social Structure 3. Interest and hobbies 4. Personal Qualities. Just like the agile manifesto, i.e, while there is value in the items on the right, we value the items on the left more. 

Where can it be used

I have been using the ‘Personal Introduction Manifesto’ since 4 years and it has proved to be of great value 

1. When a new team starts working together, helps build rapport and a personal connect between them
2. When a new member joins an existing team, new aspects of existing members come forward(they cant repeat what they said when the team was built)
3. Works very well for remote teams too
4. Ice breaker in big workshops, inceptions
5. As a team building/bonding activity
6. Visual facilitation, when people draw it themselves
7. Foster collaboration

How does it help

It helps in 

1. Creating a personal connect among new people
2. Learning more about the people you already know
3. Team bonding outside the professional connect
4. Identify people with similar interests and bond
5. Creating your personal introduction map which can be reused 
6. A document with all team member map can also be used in the on boarding deck

Over 75% of organizations struggle to design products and services that attract, engage and retain customers. Today, product & design leaders must develop effective customer experience vision to optimize customer interactions and drive business outcomes for the times to come to remain competitive.

How does one play a meaningful role in building future visions for a product or service? Can the long-term future vision be powerful enough to break through the fogginess of today’s ambiguity? Can it be a utility tool acting as a strategic direction setter? And most of all can the vision connect & motivate the teams and stakeholders to believe and stay invested in the story over time?

These were the exact questions we had in mind when we were deriving our Product visions for various clients across different domains. We have experimented with “Experience Vision”  as an early stage tool and the suitability of ‘Experience Visions’ built a strong conviction to answer a lot of these above questions.

In this talk we would like to share our practical experiences towards our approach of ‘Co-designing Experience Vision’.

CUSTOMER OBSESSION! Does this sound negative? I don’t think so… Why?

Living in a new era where Digital is the KEY, every next day brings something new on the plate. Customer asks ‘can it be quicker?’, ‘can I get more options?’, ‘Can I get additional cherry on the ice-cream?’

This change in Dynamics, have set a very high customer expectation. And it’s us, who are the culprits to set this up by doing fantabulous job and raising the bars!!

What do you think how we can compete with our own previous SUCCESS to deliver more? Or even improving ourselves looking back at our learning?

Does any methodology, approach with the right agile mind-set help customer delight? How does it compliment working with MVP. Let’s TALK…

Simply put, Product-Led Growth is a strategy that uses the product as a channel to drive business KPIs, such as revenue, engagement, and outreach without dependencies on marketing and sales or other parts of the organization.  PLG thinking primarily allows businesses to go really close to the customers to deliver impact and value via products and services.

In this talk, we are going to present the building blocks of Product Led Growth Mindset and how we were able to create a culture of building human centred value with

• a) Frictionless Product Introduction over Forced Product Adoption,
• b) Customer Engagement & Empathy over automated self-service models 
• c) Investing in User Feedback over Business Priorities
• d) Experimentation at core over long-haul roadmaps

In 2017, a couple of developers on my new team approached me with a strong feedback; they didn't understand the stories / requirements I was providing them. In fact, the stories barely had any details of how the requirement was to be fulfilled for our customers. They were frustrated and I didn't know any better because that's how I had always provided stories. I didn't want my developers to be frustrated, nor did I want my customers waiting for their requirements, so I asked my developers how they wanted their stories. What followed was the most amazing video I had ever seen until then - Josh Darnit's Exact Instructions Challenge.

It's amazing, a father asks his kids to provide with the exact instructions to make a peanut butter & jelly sandwich. Initially they fail but finally they manage to write the best instructions there could be to make the sandwich making their father (read customer) very happy and no longer hungry. That's how I should be writing my stories they said, as detailed as it can be with no room for ambiguity and that's what I did. My developers were happy, my manager was happy, my customers were happy. 2021 saw an explosion with re-share of this video by many on LinkedIn, tagged the importance of writing detailed stories and it was appreciated by hundreds if not thousands of comments. Today however, I tag this practice as an Appreciated Anti-Pattern.

What is an Appreciated Anti-Pattern? These are practices when used under a particular context prove to be counterproductive however the negative effects get camouflaged pretty well to the extent the practice receives appreciation for its efforts. And there are tens of such practices just in the space of Business Analysis alone, which is also a book that I wish to publish soon (no kidding). Take the Exact Instructions Challenge for example; yes it helps the team receive their customers' requirements on a platter which is great and highly appreciated; at the same time, it kills the conversational-negotiable-lightweight aspect of User Stories that leads to loss of self-organization, collaboration, and innovation to a great extent.

Unfortunately what I've observed is that I have spent years making this appreciated anti-pattern visible to teams after teams; in-fact a major portion of my work (life) revolves around this. And yet not many of my clients have been productive to embrace it fully; I don't blame them, it's not easy, but there's a way (a few ways actually). An extended version of the Zero Defect Policy is my way of tackling the Exact Instructions Challenge that not only improves the quality of our products but makes the teams more self-organized, more productive, more collaborative, and more innovative. Now why wouldn't one want that? That's my talk.

Note: Although I have run a number of workshops around this topic, I have never delivered a 20 minute talk around this before so please bear with me while I prepare & submit a shorter (more impactful) version of this topic for your review.

“Principles aren’t principles when you pick and choose when you’re gonna follow them." – Chidi Anagonye, The Good Place 

Have you ever been in a gnarly situation where you really struggled to make a decision? Should I go left or should I go right? Should I go over or should I go under?? Should I stay or should I go??? How the heck do you navigate these messed up situations?! And at the end of it, how do you know whether what you chose to do was ‘right’?  

Big dilemmas can get us pretty worked up, and when the emotions roll in, we often let our instincts take over, while our brains forget to think. That’s where ethics steps in. Ethics is the difference between what you have a right to do and what the right thing is. Ethics ain’t easy, but having a framework to look at complex situations supports us enables us to put the emotions to one side, and consider things more objectively. In this session we will face some big dilemmas, explore the idea of making decisions with ‘good’ reasons, and discuss how to guide and coach others to develop their ethical reasoning.

Agile principles were founded almost two decades ago.  The principles have since been contorted to placate our dopamine addiction. 

YAGNI, although not an evil in itself, has convoluted the original intent of Agile.  In this talk, I would like to show some example of how short term vision compromised a project's future, and how we, as Agile leaders, can do a dopamine detox and chart out a longer term vision in a world of instant gratification. 

Irrespective of what practice of software or school of thought of software development you come from, delivering quality software has always been at the center of your and your team’s day to day work life, as product/software quality determines Customer Satisfaction. And what defines quality software is the one with minimum bugs and the one that’s delivered on time. If your product/software did not meet either of the criteria, quality had failed.

Forbes conducted a survey with the Forbes Technology Council how they recommend speeding up software development while still focusing on quality assurance and the council came up with 16 Strategies For Fast, High-Quality Software Development and the recommendations were - 

• Focus on creating transformational value.
• Fail fast and course-correct
• Break up the deliverables
• Prioritize features based on immediate user expectations
• Manage project scope
• Lay the right foundation
• Expect and plan for mistakes
• Utilize modern development tools
• Focus on sprints and incremental changes
• Maximize parallel development and automation
• Hold frequent meetings and follow up on roadblocks
• Appoint the right project manager
• Leverage no-code platforms
• Invite the customer into the development process
• Use beta testing to refine and show progress

If you notice, there’s a common denominator that’s often overlooked - The Team. High Performance of a Team comprises two factors: Happy People + Quality Delivery.

An interpreted definition of a High Performing Team is An interdependent, stable, role-defined group of individuals who share responsibility, mutual trust and values, while having a strong leadership and a clear focus on a common goal.

Join us as we share our experiences on How to Build High Performing Teams.

Disruptive, impactful technology is built with a strong Agile mindset. It all comes down to the fundamentals - human-centric design, extremely lean product planning, strong tech practices, and steadfast focus on the intended impact to real users.

A lean product mindset helps execute disruption in unchartered territories and create high impact. Wouldn’t it be awesome if there was a cheatsheet that would work in different instances and scenarios, even under an unimaginable number of constraints?

In this talk, we share our secret sauce - the simple, repeatable principles that have worked for us time and again. 

One such circumstance: Amid Covid-19, a time of crisis became a catalyst for transformation in the rural communities of East and Southern Africa

A ship sets sail from Europe carrying Covid relief supplies for African farmers. By the time it hits the shores of Kenya, a system to ensure fair and equitable distribution of the supplies has to be put in place. This is an unknown market. Supply of electricity and internet is inconsistent. The target users’ tech literacy is limited. How do you launch a fail-safe product within a short, immovable timeline, and within several constraints? 

Despite this seeming like an uphill task, we built a distribution platform in 45 days. What’s more - it saw 10x the adoption that was predicted. Not only was the product lean and functional, it scaled seamlessly beyond the planned 200,000 users to keep up with unprecedented demand from 2 million users. 

One year later, what was once an emergency Covid relief project has evolved into a massive platform that has created and engaged an entire ecosystem around farmers. It has unlocked network effects that will add value to several lines of business, and can be launched in other geographies with minimal changes. 

This is just one instance of how large change can be effected with a lean way of thinking. We believe we have mastered the formula and listeners can use it to craft their own success stories.