Many product companies struggle with a big challenge: how to identify a Minimal Viable Product that will let them quickly validate their product hypothesis?

Teams that share the product vision and agree on priorities for features are able to move faster and more effectively.

During this tutorial, we’ll take a hypothetical product and coach you on how to effectively come up with an evolutionary roadmap for your product.

This 180 mins tutorial teaches you how to collaborate on the vision of the product and create a Product Backlog, a User Story map and a pragmatic Release Plan.

Detailed Activity Breakup

1. PART 1: UNDERSTAND PRODUCT CONTEXT
• Introduction
• Define Product Vision
• Identify Users That Matter
• Create User Personas
• Define User Goals
• A Day-In-Life Of Each Persona
2. PART 2: BUILD INITIAL STORY MAP FROM ACTIVITY MODEL
• Prioritize Personas
• Break Down Activities And Tasks From User Goals
• Lay Out Goals Activities And Tasks
• Walk Through And Refine Activity Model
3. PART 3: CREATE FIRST-CUT PRODUCT ROAD MAP
• Prioritize High Level Tasks
• Define Themes
• Refine Tasks
• Define Minimum Viable Product
• Identify Internal And External Release Milestones
4. PART 4: WRITE USER STORIES FOR THE FIRST RELEASE
• Define User Task Level Acceptance Criteria
• Break Down User Tasks To User Stories Based On Acceptance Criteria
• Refine Acceptance Criteria For Each Story
• Find Ways To Further Thin-Slice User Stories
• Capture Assumptions And Non-Functional Requirements
5. PART 5: REFINE FIRST INTERNAL RELEASE BASED ON ESTIMATES
• Define Relative Size Of User Stories
• Refine Internal Release Milestones For First-Release Based On Estimates
• Define Goals For Each Release
• Refine Product And Project Risks
• Present And Commit To The Plan
6. PART 6: RETROSPECTIVE
• Each part will take roughly 30 mins.

I’ve facilitated this workshop for many organizations (small-startups to large enterprises.)

More details: Product Discovery Workshop from Industrial Logic

Techniques

Focused Break-Out Sessions, Group Activities, Interactive Dialogues, Presentations, Heated Debates/Discussions and Some Fun Games

Target Audience

• Product Owner
• Release/Project Manager
• Subject Matter Expert, Domain Expert, or Business Analyst
• User Experience team
• Architect/Tech Lead
• Core Development Team (including developers, testers, DBAs, etc.)

This tutorial can take max 30 people. (3 teams of 10 people each.)

Workshop Prerequisites

Required: working knowledge of Agile (iterative and incremental software delivery models) Required: working knowledge of personas, users stories, backlogs, acceptance criteria, etc.

Testimonials

“I come away from this workshop having learned a great deal about the process and equally about many strategies and nuances of facilitating it. Invaluable!

Naresh Jain clearly has extensive experience with the Product Discovery Workshop. He conveyed the principles and practices underlying the process very well, with examples from past experience and application to the actual project addressed in the workshop. His ability to quickly relate to the project and team members, and to focus on the specific details for the decomposition of this project at the various levels (goals/roles, activities, tasks), is remarkable and a good example for those learning to facilitate the workshop.

Key take-aways for me include the technique of acceptance criteria driven decomposition, and the point that it is useful to map existing software to provide a baseline framework for future additions.”

Doug Brophy, Agile Expert, GE Energy

Learning outcomes

• Understand the thought process and steps involved during a typical product discovery and release planning session
• Using various User-Centered Design techniques, learn how to create a User Story Map to help you visualize your product
• Understand various prioritization techniques that work at the Business-Goal and User-Persona Level
• Learn how to decompose User Activities into User Tasks and then into User Stories
• Apply an Acceptance Criteria-Driven Discovery approach to flush out thin slices of functionality that cut across the system
• Identify various techniques to narrow the scope of your releases, without reducing the value delivered to the users
• Improve confidence and collaboration between the business and engineering teams
• Practice key techniques to work in short cycles to get rapid feedback and reduce risk

“Release Early, Release Often” is a proven mantra, but what happens when you push this practice to it’s limits? .i.e. deploying latest code changes to the production servers every time a developer checks-in code?

At Industrial Logic, developers are deploying code dozens of times a day, rapidly responding to their customers and reducing their “code inventory”.

This talk will demonstrate our approach, deployment architecture, tools and culture needed for CD and how at Industrial Logic, we gradually got there.

Process/Mechanics

This will be a 60 mins interactive talk with a demo. Also has a small group activity as an icebreaker.

Key takeaway: When we started about 2 years ago, it felt like it was a huge step to achieve CD. Almost a all or nothing. Over the next 6 months we were able to break down the problem and achieve CD in baby steps. I think that approach we took to CD is a key take away from this session.

Talk Outline

1. Context Setting: Need for Continuous Integration (3 mins)
2. Next steps to CI (2 mins)
3. Intro to Continuous Deployment (5 mins)
4. Demo of CD at Freeset (for Content Delivery on Web) (10 mins) – a quick, live walk thru of how the deployment and servers are set up
5. Benefits of CD (5 mins)
6. Demo of CD for Industrial Logic’s eLearning (15 mins) – a detailed walk thru of our evolution and live demo of the steps that take place during our CD process
7. Zero Downtime deployment (10 mins)
8. CD’s Impact on Team Culture (5 mins)
9. Q&A (5 mins)

Target Audience

• CTO
• Architect
• Tech Lead
• Developers
• Operations

Context

Industrial Logic’s eLearning context? number of changes, developers, customers , etc…?

Industrial Logic’s eLearning has rich multi-media interactive content delivered over the web. Our eLearning modules (called Albums) has pictures & text, videos, quizes, programming exercises (labs) in 5 different programming languages, packing system to validate & produce the labs, plugins for different IDEs on different platforms to record programming sessions, analysis engine to score student’s lab work in different languages, commenting system, reporting system to generate different kind of student reports, etc.

We have 2 kinds of changes, eLearning platform changes (requires updating code or configuration) or content changes (either code or any other multi-media changes.) This is managed by 5 distributed contributors.

On an average we’ve seen about 12 check-ins per day.

Our customers are developers, managers and L&D teams from companies like Google, GE Energy, HP, EMC, Philips, and many other fortune 100 companies. Our customers have very high expectations from our side. We have to demonstrate what we preach.

Learning outcomes

• General Architectural considerations for CD
• Tools and Cultural change required to embrace CD
• How to achieve Zero-downtime deploys (including databases)
• How to slice work (stories) such that something is deployable and usable very early on
• How to build different visibility levels such that new/experimental features are only visible to subset of users
• What Delivery tests do
• You should walk away with some good ideas of how your company can practice CD

Slides from Previous Talks

Over the last few years, while building products, I’ve really struggled to keep my users engaged. Its been hard to have your users constantly coming back to your product. There is a fine line between being too pushy and fading away in the background.

Today I was pleasantly surprised to see the following email from LinkedIn.

This email has the right balance. It makes you feel important and wanted.

Doing this kind of stuff in products is generally hard. Also I was surprised how they have figured out the related groups and suggesting those to me. Interesting!

Risk and Reward goes hand-in-hand: Overall Services business pays fairly well and its relatively less risky. Product companies have to face all kinds of risk. Starting with what to build, how to market it, how it price it, how to sustain it and so on. But if you can figure out answers to these questions, then Products do pay off really well.

Business Model: Services has a straight forward model. Increase per head revenue and increase head-count. It also has a fairly predictable cash flow. You bill for the time your spent. Product companies have complicated business models. There is very little co-relationship between time spent and revenue. Figuring out the right business model for your product is in fact one of the biggest challenge.

Lifestyle: Services can be extremely stressful or extremely easy going. Depending on the nature of the service, you could have very unpredictable work flow. Causing work to come in unsustainable batches. Usually services involves quite a bit of travel. Generally not good for family life and health. On the other hand, Product developer is usually stressful, but predictable. Lot better on family life and health.

Growth: Services provides you a linear growth path. It depends on the number of customers, number of employees and number of locations you operate in. Product companies usually follow a non-linear growth path. Growth really depends on the value created by your product for the consumer. There is no direct relationship between growth and number of employees or locations you operate in.

Valuation: In services companies, its employees and customer-base are its real assets. If employees are gone, the value of the company is almost zero. For product companies, the product itself is an asset. Good customer-base certainly increases the valuation of the product.

Customer-base: Usually services (at least consulting and training) companies have to deal with dysfunctional organizations (mismanaged expectations and huge communication problems). Working with dysfunctional companies is very depressing and there is not much to learn. And hence not very motivating. Building our own products at least shields us from some of that.

Freedom of choice: In services, you need to work inside the constraints of the client. There isn’t much freedom in-terms of tools, domain, technology, etc. Product companies usually offers a much broader choice. Which usually leads to more experimentation and more accidental innovations.

Bootstrapping: Good skills and reputation is enough to get started in services. It can be gradually scaled out. You can be cash-flow positive from day 1. However for product companies, getting to positive cash-flow takes time and effort. Finding paying customers quickly is hard. In general bootstrapping a product company is a lot harder.

Innovation: Both services and product companies thrive on innovation, but they are different kinds of innovation. Services is driven by innovation in implementation and service quality. While in product companies lot more innovation is required in ideation and in scaling.

Employee’s Attitude: In Product Company you generally Live to Work, whereas in Services Company you could Work to Live. At a Product company you feel your Product is like your own baby, in Services Company you are just Baby Sitting.

Every now and then, I run into some weird issue with a software that I truly depend on. What I’m trying to do, looks like a very valid scenario, yet the software just does not want to cooperate. I look at their error message, it is completely misleading. You try to logically reason it out, but you run out of reasons.

Just when you are about to loose hope, you google for the error message and you find a huge number of other users offering solutions. Some problems might be very old know issues, but the folks building the software just never got around to fix them. However, with the help of suggestions from other users, you are able to very quickly solve your issue.

Instantaneously your frustration with the “poor quality” software disappears. You start to love the software even more.

This might sound dramatic, but this is my experience.

For Example: Recently I noticed that my blog, which runs on wordpress, did not have any description meta-tag.

Asked myself:

Shouldn’t wordpress produce a decent  description for each blog post? Guess not!

So I googled for it. Found an easy enough solution. Implemented it. Worked well, except, I started getting the following error on all admin pages:

Warning: Cannot modify header information – headers already sent by (output started at

It says its a Warning, but its a show-stopper. Does not even let me access the admin screens. However people can view my blog just fine.

Again googled for the error message and found a solution. Fixed it. Life is good.

This is the power of having a great community of users. User issues can be fixed in a fairly decentralized way.

Also we all know that “Zero-Defect-Product” is a myth. Any interactive system, can never be fully specified nor fully tested. There will always be scenarios that your team did not think about, but your users are trying to use the product in those scenarios.

So my point is:

Your software might have issues, but sometimes the community can figure out the solution and share it with others, faster than your company can. It does really compensate for not having the highest quality product.

In other words:

You can get away with slightly lower quality product if you are able to build a great community of users around your product.

Of course, if you have a crappy product that does not add any value to any users, then you won’t be able to build a community, no matter how great the quality of your product is.

Also I’ve seen many products that keep everything so closed/secretive, that even if a user wants to help, they simply cannot.

Personally I think those days are gone. This is the era of “more power to the users“ and “more dependence on the users“.

I don’t think productivity is directly influenced by time alone. There are other important factors which make it or break it.

• There are days when I can get a lot done in lot less time and other days life moves slower than a snail.
• There are days when I can stay very focused and productive for up to 15-16 hrs and there are days when couple of hours of work seems like torture.
• There are certain type of tasks that I can get very productive very quickly and certain type of tasks which takes times to get into the flow.
• If I have a vested interest (financial, reputation, learning, etc.), I train myself to stay focused and productive longer (can back-fire as well.)
• There are phases of one’s life when one can clock in more hours and there are phases where one cannot; other things are higher priority. If forced (soft or hard), it usually leads to wrong behavior.
• I’ve seen many people who are very deadline driven (including myself.) I get a lot done when I’m working against hard deadlines. Yes, quality certainly takes a hit, but in many cases delivering slightly lower quality stuff is more important than not delivering at all or delivering later.

If we look at these various aspects, we get close to a start-up environment. And under these conditions, we do see teams being quite productive and delivering interesting products.

Applying this in a different context/environment usually back-fires.

What do you think?

This blog post was trigger by Tim Berry's blog post on Productivity Paradox: Maybe Less is More.

Branching is a powerful tool in managing development and releases using a version control system. A branch produces a split in the code stream.

One recurring debate over the years is what goes on the trunk (main baseline) and what goes on the branch. How do you decide what work will happen on the trunk, and what will happen on the branch?

Here is my rule:

Branch rarely and branch as late as possible. .i.e. Branch only when its absolutely necessary.

You should branch whenever you cannot pursue and record two development efforts in one branch. The purpose of branching is to isolate development effort. Using a branch is always more involved than using the trunk, so the trunk should be used in majority of the cases, while the branch should be used in rare cases.

According to Ned, historically there were two branch types which solved most development problems:

• Fixes Branch: while feature work continues on the trunk, a fixes branch is created to hold the fixes to the latest shipped version of the software. This allows you to fix problems without having to wait for the latest crop of features to be finished and stabilized.
• Feature Branch: if a particular feature is disruptive enough or speculative enough that you don’t want the entire development team to have to suffer through its early stages, you can create a branch on which to do the work.

Continuous Delivery (and deployment) goes one step further and solves hard development problems and in the process avoiding the need for branching.

What are the problems with branching?

• Effort, Time and Cognitive overhead taken to merge code can be actually significant. The later we merge the worse it gets.
• Potential amount of rework and bugs introduced during the merging process is high
• Cannot dynamically create a CI build for each branch, hence lack of feedback
• Instead of making small, safe and testable changes to the code base, it encourages developers to make big bang, unsafe changes

P.S: I this blog, I’m mostly focusing on Client-Server (centralized) version control system. Distributed VCS (DVCS) have a very different working model.

How good are you at limiting red time? .i.e. apply limiting WIP (Work-In-Progress) concept to Programming and Product Development.

What is Red Time?

• During Test Driven Development and Refactoring, time taken to fix compilation errors and/or failing tests.
• While Programming, time taken to get the logic right for a sub-set of the problem.
• While Deploying, downtime experienced by users
• While Integrating, time spent fixing broken builds
• While Planning and Designing, time spent before the user can use the first mini-version of the product
• And so on…

Basically time spent outside the safe, manageable state.

Let it be planning, programming or deploying, a growing group of practitioners have learned how to effectively reduce red time.

For example, there are many:

• Refactoring Strategies which can help you reduce your red time by keeping you in a state where you can take really safe steps to ensure the tests are always running.
• Zero-Downtime Deployment which helps you deploy new versions of the product without your customers experiencing any downtime.
• Continuous Deployment which helps you get a change made to code straight to your customers as efficiently as possible
• Lean Start-up techniques which helps validate business hypothesis in a safe, rapid and lean manner.
• And so on…

I highly recommend watching Joshua Kerievsky’s video on Limited Red Society to gain his insights.

Over the years we’ve realized that it always helps to have simple tools to visualize your red time. Visualization helps you understand what’s happening better. And that helps in proactively finding ways to minimize red time.

At Industrial Logic we have a new product called Sessions which helps you visualize your programming session. It highlights your red time.

On many applications I’ve worked on, Authentication is a big pain.

• Usually its an usability hazard. (No one likes to authenticate themselves over and over again)
• Since its a cross-cutting concern and every application has some special logic for authentication, we spend way too much time hand crafting the best strategy to implement and test it to make sure our application is secure.
• When you have multiple applications and you want to implement single-sign-on, the pain just exponentially amplifies.
• On high scalability apps, Authentication (session validation) can be expensive from performance point of view

In the search of simplicity, I’m wondering if there are alternative techniques to implement authentication on certain types of applications.

One thought comes to my mind, which I’m curious to try. I’ll start with a very specific example and then expand it to other applications.

While building web applications in the category of social networking or eLearning or some other category, where retrieving data from the app is not very critical from a security point of view:

Even if you have a stale session cookie, GET request works fine without requesting you to authenticate. Only when you POST, authentication kicks in.

This approach will certainly not work for a banking application, where reads also have to be very secure. But for many application reads don’t need to be very secure. Also most applications have relative very small number of POST requests, which means very few times the user would be nudged to authenticate themselves. Most RESTful frameworks can have this built in.

Can this approach be used for rich-client apps instead of just web-apps? I think so.

What am I missing?

A prioritized user story backlog helps to understand what to do next, but is a difficult tool for understanding what your whole system is intended to do. A user story map arranges user stories into a useful model to help understand the functionality of the system, identify holes and omissions in your backlog, and effectively plan holistic releases that delivery value to users and business with each release.