CSC301, Lecture 7

Joey Freund, CSC301, Fall 2014

Midterm

• A few issues we noticed:
• The difference between git commit and git push.
• Focusing on the highest priority features/stories of a product.
• In CRC cards, the difference between collaborator (i.e. dependency) and a subclass (i.e. inheritance).
• Cohesive OO design.
• Let’s review the midterm …

More on Product and Process ...

• Let’s look at an interesting case study.
• The product: TodayLaunch
• A social media management system.
• Used by marketers, advertisers and PR professionals to manage their clients’ presence and exposure on various social media channels.
• Company: TodayMade.

Case Study

• Founders’ observation: Social Media Management is hard.
• The founders had some experience managing clients’ social media channels, and understood the needs of (some) users.
• Existing tools were too complicated.

Case Study

• Hypothesis: Business owners needed to do three things in order to succeed:
• Respond
• Connect
• Learn
• Next step - Build an MVP to validate (or invalidate) the hypothesis.

Case Study - MVP

• Simple web app.
• Clean interface with 3 tabs, one for each main action.
• MVP Built in 2-3 weeks.
• The product had a lot of issues, but it allowed the founders to make a sale.

Case Study - MVP

• Contacted 10 local businesses.
• Had 6 successful meetings/demos.
• Potential customers were overall interested.
• Resulted in 1 sale, and a few free customers.

Case Study - lessons Learned

• The team learned a few lessons from their meetings:
• Customers wanted simplicity (as suspected).
• The solution was clear, but didn't fit existing workflow.
• Monitoring was not so important.
• Yes to the inbox.
• Adopters, not establishment (i.e. what type of customers to look for).

Case Study

• The team finished the work, and shipped within two weeks.
• The product had many issues, but the feedback was positive enough to encourage them to keep going.

Case Study - Second Iteration

• The second iteration started with a few ideas/goals:
• More familiar design (it’s not bad to look like the competition).
• Better naming conventions (in the product, not the code).
• Find good ways to teach users how to use the product.

Case Study - Second Iteration

• Interface was changed, and better terminology was used.
• Developed a basic training program.
• 3 hours long.
• Live session.
• The clients learned about the product, and the team learned even more about the clients.

Case Study - Reality Check

• A “fully baked” version was built, based on the team’s guesses and intuition.
• The problem … business was not growing.
• Even worse …
• The product became too complicated, and (the team felt that it) required serious interface work, and complete backend rewrite.

Case Study - Reality Check

• The team spent the next year rebuilding.
• They chose to build a complete new product, instead of another MVP.
• Created a few versions that were never released.
• Productivity went down.
• Not focusing on collecting feedback.
• Generally losing hope and momentum.

Case Study - Positive Change

• A few key decisions:
• Changing the pricing model.
• Picking up modern technologies to allow for faster software development.
• Focusing on delivering small batches.
• Focusing on collecting feedback.

Case Study - Using Data

• Instead of asking for feedback, extract useful information from data you already have.
• Business owners don’t bother developing a social media strategy.
• Users weren’t using monitoring tools effectively.
• Active users actually like the product.
• New features were adopted, and being used.

Case Study - More Feedback

• Next, the team conducted a survey, and realized that:
• Users want to keep using their product.
• Almost all of their users view them as a competitor of HootSuite (a very big player in their market, based out of Vancouver).

Case Study - More Feedback

• With that in mind, they started looking at the competition:
• What do they do well?
• What are users complaining about?
• How to differentiate the product from the competition?
• There are users who don’t want the product of the biggest player in the business. Try to focus on their needs?

Case Study - More lessons learned

• Their product already solved some problems that users had with the competing product. They just had to let users know (i.e. marketing work).
• It is possible to compete with a well-funded huge player, by focusing on a smaller market share.

Case Study - Growing

• After two years of “paying their dues”, the team started moving faster:
• MVP built in a month.
• New release every month.
• fully-paid service within 6 months.
• More signups in one day than the whole previous month.
• Using various analytics tools to continuously improve the product and business.

Case Study - Summary

• Agile is more than just a buzzword.
• It is an attitude that is applied to every aspect of your company: Technology, product, marketing, business, etc.
• It allows small startups to compete with well-funded organizations.

Let’s take a quick break ...

Abstract Factory Design Pattern

• The problem:
• Our application creates objects of type X.
• X is an interface (or an abstract class).
• Our application should not depend on any specific implementation of X.
• The solution:
• Pass the responsibility of creating objects to someone else.

Abstract Factory Design Pattern

• Let’s see an example.
• You can also read another description of this design pattern here.

Design Patterns

• Passing the responsibility of object instantiation to someone else is related to another pattern, called Dependency Injection (or Inversion of Control).
• We will not cover DI/IoC in details, but I thought I should mention it, in case you run into it at some point.