In software world we call this speculative generality or YAGNI or over engineering.

IMHO we should not be afraid to throw parts of your system out every 6-8 months and rebuild it. Speed and Simplicity trumps everything! Also in 6-8 months, new technology, your improved experience, better clarity, etc. will help you design a better solution than what you can design today.

Just to be clear, I’m not suggesting that we do a sloppy job and rewrite the system because of sloppiness. I’m recommending, let’s solve today’s problem in the simplest, cleanest and most effective/efficient way. Let’s not pretend to know the future and build things based on that, because none of us know what the future looks like. Best we can do is guess the future, and we humans are not very good at it.

Recently I wanted to create a video demo of my iPad apps. So I thought, I would just walk-through the apps and capture the screen on my iPad. It turns out that its not as simple as I thought it would be. While the desktops have a ton of screen-casting software, iPad simply lacks any of these sophisticated software.

When I googled for screen-casting apps on iPhone/iPad, I found a huge number of apps, but all of them are mostly whiteboard apps, that let’s you capture the screen inside their app (more useful for teachers.)

Searching some more, helped me find a few viable options:

• Create a Screencast Video using Screenshot Images – Extremely painful. I’ve done this approach in the past. I would take these images, add it to a Keynote presentation, add a few animations/transition effects and then export the presentation as a video.
  
• Use an iOS Simulator with a Desktop Screen-capture tool – The most widely used and probably the first approach to creating demos was using the iPhone/iPad simulator on your Mac, while recording your Mac screen with QuickTime. Sound Stage looks like a cool app for recording your screen and adding some nice mojo to it.
• Use Display Recorder Utility to Capture on screen activity on your iPhone /iPad Screen – This app was removed from the app store, so the only way you can get this app is to install it via Cydia, which requires your device to be jail-broken.
• Use a Video Capture Card – Using a HDMI Adapter, connect the output of your iOS device to a video capture card.
• Use camera mounts for usability testing of mobile devices – This approach is great for usibility testing where you want to see the hand-gestures and facial expression of the user, but in our case this might be an overkill. BTW I really like Mr. Tappy, a kit for filming mobile devices. Originally designed as a filming rig for iPad usability testing, Mr Tappy lets you capture or share user interaction with mobile devices during user experience research, product demonstrations or classroom presentations.
• Mirror the iPhone/iPad screen via AirPlay and record it – This seemed like the easiest option for me. There are a couple of apps (Reflector, AirServer) available, which you need to install on your desktop. Once installed, you can go to your iOS device and start mirroring the screen on to your desktop. Not only does it mirror the screen, but it also uses the desktop to actually play the sound. And all of this over a wireless network. Once the iOS device’s screen is on your desktop, you can use QuickTime to easily capture the video.

Once I recorded by screen-cast using AirServer and QuickTime, then I used iMovie to do some minor editing and adding some annotations to the video. That’s it. I recorded the following 2 videos if you want to have a look.

Over the last few months, multiple friends and connection from US have asked me to share my experience with pricing Agile related tools and services in Asia (specifically India.) Following is my perspective:

Disclaimer: Asia is the most diverse and dynamic continent out there. Any reasonable generalization is bound to have loopholes. Take it with a pinch of salt.

Since the topic on hand is pricing & positioning agile related services and tools, let’s focus on senior managers at software companies, who are interested & responsible for procuring (or at least recommending) a service or a tool for use inside their company. These folks mostly belonging to upper-middle class or above. Its important to focus on these folks because we can draw the following behavioral patterns based on their profile:

• 1. They are very value-for-money conscious. .i.e. while they are very price conscious these days they are also getting quite brand conscious. Feature-richness or “fully-loaded” appeals to them because they associate it with value-for-money.
• 2. Premium pricing model works well with them. .i.e. price the product or service artificially high in order to encourage favorable perceptions among buyers. Exploits the tendency in buyers to assume that expensive items enjoy
  • an exceptional reputation,
  • are more reliable or desirable,
  • represent exceptional quality and distinction
• 3. If they can’t bargain the price while buying, they feel they did not get a good deal.
• 4. In my experience, Freemium model generally does not work very well. People will somehow find a way to stay on the free plan. Software Piracy is still a notable problem. Things like sharing a license with others is considered wrong, but people will still go ahead and indulge in it. May be because they don’t fully think through the implications or can’t empathize with IP related regulations.
• 5. Price Discrimination strategy appeals to these folks. .i.e. pricing the product differently for different companies. Bigger discount for larger number of licenses is common. But doing something more like: bigger discounts for startups or discounts for specific verticals like Telecom can attract customers.

Based on my experience consulting and coaching IT companies in India, I would categorize Indian IT companies, who are interested in Agile, into the following 5 categories:

• 1. Large Outsourced Services Organization (InfoSys, Wipro, TCS, CTS, HCL, MindTree, TechM, etc.)
• 2. Large ODC (Off-shore development centers) for giant software product companies (Google, Yahoo, Amazon, Microsoft, Intel, McAfee, EMC, Philips, Dell, GE, Siemens, VMWare, Alcatel Lucent, Ericsson, Aricent, Huawei, etc.)
• 3. Large ODC for large non-software product/services companies (Banks and Financial Institutes [JP Morgan, Citi, RBS, Fidelity], Store Chains [Tesco, Walmart, Target], Transportation [Volvo, John Deere], etc.)
• 4. Mid-size product and services companies (Directi, SlideShare, ClearTrip, Cactus Global, etc.)
• 5. Startups (Eko, Interview Street, CommonFloor, HelpShift, OlaCabs, Olx, Zomato, etc.)

Category 1 is highly obsessed with process adherence & compliance. Typically they have an internal process & tool which all projects have to use. In addition, clients of most projects might have a different process & tool required. Teams end up using both. Most teams use different tools because there are concerns regarding how much transparency is healthy for an outsource client-vendor relation. They want only limited data to be shared with the clients. In fact in my experience, to ensure company-wide consistency and compliance, most companies even have their own home grown tool/solution to deal with this issue. If majority of customers are using a process/tool, its an easy pitch to the companies to use the same approach, provided there is an easy way to share limited info with clients. Using same process/tool could add to the company’s marketing/credibility pitch. These companies are price conscious, but if the value proposition (better customer acquisition) is shown, they have the budgets to buy the tool or service. Might require multiple rounds of negotiation. They are willing to commit higher numbers if bigger discounts can be offered. Fairly long sales process.

Category 2 is fairly process conscious, but certainly to a lesser extent compared to Category 1. For these companies majority of the process and tool decisions are made by their counter-parts from west. They do have a say, but are not going to make the buying decision. However they can sabotage the process/tool decision if it does not work for them. Because of the “distributed & off-shore” nature of work, their needs might be different from the folks making the decision. These guys appreciate higher attention/care to their specific needs. Sales process tends to be much faster than Category 1.

Category 3 is also very process conscious. They are predominantly cost centers. Any tool or process which can show clear cost saving, better accountability & tracking is a big hit. Buying decisions are jointly made, however offshore folks do have a big say. Typically these folks require quite a lot of customization to the service or tool to fit their specific needs. Sales process tends to be very long.

Category 4 is out of the startup mode, and are the “wanna-be-enterprise” scale. These are in my opinion the best companies to chase for process change and tool adoption. They have the right attitude to change. Typically they also have the cash and they generally don’t bargain much. They have a strong desire to scale and standardize. Perfect pitch for a Industry Leading Tool to come in and steal the deal. Again these guys don’t tend to bargain too much, but if you give them a discount it will help make the decision faster because they are still price conscious. These guys will do a very detailed market study & competitor analysis. If possible, they prefer to pick the best in category. Sales process tends to be either couple of days or 6+ months (extremes.)

Category 5 is the least process conscious. However are very efficiency & savings driven. They won’t even talk to you if they feel the product is priced and targeted at Enterprises. They would assume/feel the product is expensive and too heavy-weight for startups. A clear pitch for startups in your offerings is very important. These folks will hunt you down. Again very price conscious, but can be good brand ambassadors. Sales process does take some time.

Hope this helps. Also would be keen to hear your experience.

In the last couple of months, I’ve got several requests from top-notch product companies in India, asking me to facilitate a hands-on workshop on decision making using Lean-Startup’s hypothesis validation techniques for their Executive and Senior Management. I’m thrilled to know that companies are seriously exploring these options.

Following is a 1-Day workshop which I’ve successfully ran a few times:

Experimentation Driven Decision Making Workshop

Large number of products/services fail today, not because they cannot be built and delivered, but because the entrepreneurs building those products/services are disconnected from the people consuming them. This disconnect, leads to early assumptions about consumer’s behavior and motivations. To one’s surprise, these decisions can turn out to be based on stupid (read as: deadly and risky) assumptions.

Traditionally, entrepreneurs believed that the only way to test their product/service hypothesis was to build the best product/service in that category, launch it, and then observe user behavior. And of course the big bucks spent on marketing campaigns. Surprise! Surprise! This can be a very time consuming & expensive process; not to mention the huge opportunity cost.

(src: Kent Beck)

Luckily today, we know that many entrepreneurs are using Lean-Startup methodology’s Customer Development practices to help them make important product/service decisions (cheaply) based on Validated Learning.

This workshop will give you a hands-on experience to formulate and quickly test out your value and growth hypothesis.

Process/Mechanics

This is a group activity and the participants have to work in small groups.

In the first one hour of the workshop, each group has to come up a product/service idea, which they believe will really succeed. Then they craft out the elevator pitch about the product/service and put together a basic business model. Post that, the group has to clearly highlight what are their value and growth hypothesis.

The rest of the workshop is dedicated to the participants trying to validate their hypothesis. They can use phone and/or Internet to do their research and validation. The best results, of course, are got when the participants meet real people face-to-face to validate your hypothesis. I’ve seen participants wait outside restaurants, cafes, health-clubs, malls, etc. to run their tests. Some participants also get really creative and build some paper prototypes or fake products to validate their hypothesis. Using a fake credit card swiping machine to see if people will really pay is one of my favorite validation techniques so far.

It always amazes me how creative people can get during this process. Also it’s very fulfilling to see the “Aha moment” on the participant’s face. I can’t describe in words, the shocked look on their faces, when they spend the day validating their hypothesis and discover various hidden assumptions about their target user’s behavior.

Learning Outcome

• Learn how to decide which assumptions you MUST absolutely test.
• Understand why just marketing metrics won’t help you make a better product/service.
• Master the art of leveraging the Minimum Viable Product to create maximum validated learning for minimum cost.
• Learn how to systematically decide when to Pivot to a new strategy.

Workshop style

Interactive dialogues, case studies, hands-on group activities, and on-field exercise.

Good Product Owners are:

• Visionary
• Can come up with a product vision which motivates, inspires and drives the team
• Aligns the product vision with company’s vision or mission
• Passionate Problem Solver
• Should have a knack of identifying real problems and ability to visualize a simple solution to those problems.
• Has good analytical & problem solving skills
• Subject Matter Expert
• Understands the domain well enough to envision a product to solve crux of the problem
• Able to answer questions regarding the domain for those creating the product
• End User Advocate
• Empathetic to end-users problems and needs
• Able to describe the product from an end-user’s perspective. Requires a deep understanding of users and use
• Is passionate about great user experience
• Customer Advocate
• Understands the needs of the business buying the product
• Ability to select a mix of features valuable to various different customers
• Business Advocate
• Can identify the business value and synthesize the business strategy as measurable product goals
• Has a good grasp of various business/revenue models and pricing strategies
• Capable of segmenting the market, sizing it and positioning a product (articulate the Unique Selling Proposition)
• Is good at competitive analysis and competitor profiling
• Able to create a product launch strategy
• Communicator
• Capable of communicating vision and intent – deferring detailed feature and design decisions to be made just in time
• Decision Maker
• Given a variety of conflicting goals and opinions, be the final decision maker for hard product decisions
• Designer
• Possess a deep understanding of (product) design thinking
• Able to work effectively with an evolving product design
• Planner
• Given the vision, should be able to work with the team to break it down into an iterative and incremental product plan
• Capable of creating a release roadmap with meaningful release goals
• Is feedback driven .i.e. very keen to inspect and adapt based on feedback
• Collaborator
• Able to work collaboratively with different roles to fulfill the product vision. Be inclusive and empathetic to the difficulties faced by the members of the cross-functional team
• Given all the different stakeholders should be able to balance their needs and priorities
• Empowers the team and encourages everyone to try new ideas and innovate

Disclaimer: This list is based on my personal experience but originally inspired by discussions with Jeff Patton.

In my experience its hard (not impossible) to find someone who possess all these skills. It requires years of hands-on experience.

Some companies form a Product Ownership team, comprising of different people, who can collectively bring these skills to the table. Personally I prefer supporting one person to gradually build these skills.

I amazed how easily companies get convinced that they can send their employees to a 2-day class on Product Ownership and acquire all these skills to be a certified Product Owner.

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 workshop, we’ll take a hypothetical product and coach you on how to effectively come up with an evolutionary roadmap for your product.

This day long workshop 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“.