Requirements and Product Planning

I found a college paper of mine on Requirements and Product Planning, so I figured I’d publish it online. You can view it on Scribd here or embedded at the bottom. Here’s a full outline (lightly edited) that I wrote before writing the paper:

Requirements and Product Planning Outline

Short product design plans combined with prototypes and diagrams are usually more effective means for finding and communicating the plan of a product than detailed written requirements. 

  • Finding and communicating the right requirements are the most important part of a project. It is therefore crucial to find the right approach.
  • The earlier you mess up, the worse is it is. The early decisions decide the direction of everything. So if you make wrong choice and only discover later, you will have to throw away a large amount of work. Studies showing how crucial the requirements stage is.
  • Definition of requirement – what the product must do to solve a user’s need.
    A full requirement answers these questions (Motorola):

    • Who it is for (E.g. The world, doctors, 54-year olds)
    • What it will do (E.g. Actions, results..)
    • Describe the full user experience and accurately represent the behavior of the software
    • Additional questions – Where, When and How well.
  • The purpose of requirements:
    • To accurately describe user experience and software behavior so all parties can understand it.
      • The requirements should be able to be communicated to customers, engineers, marketing and any other parties so they all know what the product will be.
    • To aid in finding the right product and refine until satisfactory
      • Sometimes will want to adjust the product, so need to specify first and then refine the requirements before building the actual product.
  • Ways to find ideas and determine the requirements
    • Market research tools and their limitations
      • Customer surveys and interviews
      • Analytics, data mining and social analysis
      • Site visits and focus groups
      • Usability testing.
      • Competitive analysis

This research may help gather data, but it will not determine what features or product to build. To determine what to build need to go beyond that.

  • Ideas and testing them with users
    • Need to determine how technology will be used to solve certain problems and what the user experience will be.
    • To do this, need to recognize the problem and understand what potential technology can be used to solve it.
    • This is how practically all successful tech companies built their products, not with market research. For example:
      • The Google founders invented a new algorithm to ranks search results which made them more relevant and higher-quality than what existed before.
      • Facebook developed a successful social network by figuring out what people would want most long-term in such a site. For example, they placed certain restrictions on users (like a real-name policy or set profile page) that helped them become successful.

They didn’t use market research, they were able to figure out what people would want and how to do it with technology.

  • Ideas are nice, but need to verify if they will work, since gain nothing from products that people do not want (at least in capitalist countries!)

As mentioned above, a primary purpose of requirements is to be able to refine product early in game to avoid large costs later.

  • Approaches to formulating and communicating requirements:
    • Full, formal text requirements (Motorola book)
      • This used to be the standard corporate practice in big companies.
      • These formal requirements are similar to an engineering process of e.g. a bridge or building.
      • In full, it can include five steps of engineering:
        • Elicitation – Discover requirements by consulting stakeholders.
        • Analysis and Negotiation – checks if requirements meet certain criteria, such as consistency, completeness and feasibility.
        • Documentation – for communicating them.
        • Validation – Check if it describes the system well and if there are problems.
        • Management – Manage the requirements. To track and develop complex requirements, can use a Database Requirements Management Tool, which provides various benefits. (Motorola)
    • Full prototype (Inspired book)
      • Create a throwaway prototype (using tools that make it fast) to show the various activities that will be possible. Parts that cannot be built into prototype should be simulated.
        • “Realistic representation of the proposed user experience”
        • Comprehensive coverage of the site – Prototype “should represent the functional requirements, the information architecture, the interaction design, and the visual design of the user experience.”
      • Another possibility is to use an evolutionary approach. Develop a very simple version of the site and then use that as basis for the actual site. However, if the foundations of the site are not well-designed, the site will always have problems.
    • Proposed middle approach
      • Short product design description, combined with wireframe/prototype to show overall idea and diagrams or visual representations (such as UML). Instead of full text requirements, can just use “Use Cases”.
  • Comparing the effectiveness of different approaches:
    • For discovering the right features and product, and testing them
    • For communicating to relevant parties (so they know what to do)
  • Each approach analyzed:
    • Full text requirements
      • Pros – Everything is spelled out. People should know what specifically needs to be done and when meet the criteria.
        Sometimes it is necessary to have very specific requirements – for example, if very specific critical criteria need to be met, such as software for a bank or nuclear plant.
      • Cons – Takes time to create, complex, but may be difficult to understand. Cannot test with users.
        The fundamental issue with full requirements is that they assume “It is possible to determine a stable set of requirements before system design and implementation starts.” With many web products nowadays, that is not exactly true.
    • Full prototype
      • Pros – Clearly shows how it works and this can be used to communicate well with all parties. Can also test product on actual users before building the real thing.
      • Cons – Can take a while to make and is redundant with later efforts. Additional problem is if it does too many details such as the UI, it will be describing “How” to do it before the “What” that requirements are supposed to be focused on.
    • Proposed best way – Compromise, but focused on the lean way – Minimum prototype, minimum product design plan (focused on use cases), clear diagrams, etc. to show all aspects of product.
      • Pros – Can efficiently create it, it can communicate effectively, can help find the right ideas, more flexible, allows for some testing before create product.
      • Why this approach is better than long detailed text requirements:
        • This approach fits better in web age as opposed to box shipped stuff. Since can iterate and develop new features quickly, do not have time for long requirement process.
        • Use cases and prototypes (and software tests) combined can meet the needs of requirements. The use cases describe the overall needs and the prototype can show the different parties what the product will do to meet them. Additional details can be shown with basic charts, but extensive detail is not necessary.
        • Outlines and visual charts are better since they communicate the ideas more quicker than long text. They can also be made more quickly, since one does not need to “textualize” the ideas by turning them into paragraphs.
      • However, this approach has some of the cons of each approach above, so need to find right balance. For example, can make sure prototype is built quickly with a focus on just communicating what the product will do.
  • While standard practice may have been to follow more formal and longer requirements system, this is becoming less common. Part of the reason for this is the overall differences between agile and traditional development methods:
    • Agile methods are adaptive rather than predictive.
    • Agile methods are people-oriented rather than process-oriented.

As mentioned, this is partially due to changing nature of web products where everything must move much faster. There is much less reason to use a complex formal process for developing products (especially consumer ones) on the web. Some companies may be used to older methods, or they may be developing products where it is important to get everything right. But this approach is no longer needed for most consumer software products.

JOBS Act and the Crowd-Sourced Startup

In April 2012, the JOBS Act was signed into law, but the SEC has been slow to implement it. The first part of the act will finally become active tomorrow, which will allow startups to publicly announce that they’re fundraising. However, they will still only be able to raise money from accredited investors, i.e. rich people.

Phase III of the JOBS Act will allow crowdfunding – ordinary people will be able to invest small amounts of their income in startups (see Crowdfunding passes in the Senate). This will help many small companies and startups raise money from a large number of people. Currently, a person or company can raise money on a site like Kickstarter, but can only offer backers rewards (like their product or tshirts), but not equity in the startup. Imagine how many more people will be interested in backing startups if they can hope to get rich from doing so! This will raise the risk of scams though, which is why there will be various regulations on crowdfunding once it is (eventually) implemented.

Startups will be able to raise money from the public, and could also use their “crowd” of investors to help to do things for their company. For example, a company could perform market research with their crowd investors, or ask them to help promote the company’s product on social media. Quirky uses its crowd to help decide what physical products to create, so tech companies could consult with their crowd to help decide on new features for an app.

Perhaps a company’s crowd could  be consulted with to work on a specific task, such as creating some icons for a site or improving its SEO. Crowd investors will want to be compensated for large tasks that they do, but it could still be easier to hire someone already invested in the company than an external consultant. In fact, maybe this work could be an alternative form of crowdfunding – instead of investing in a company, people could contribute work and get a share of equity. This would differ from standard employment for equity since it the work would be distributed to a large number of people. While this could make collaboration more difficult, many open-source projects have been successful with a large number of contributors, so perhaps startups can do the same thing.

Paul Graham once said:

I don’t think crowdfunding is good for startups. For startups, having large numbers of investors is bad, and having inexperienced investors is bad. So having a very large number of inexperienced investors is the worst scenario possible.

 

While too many ordinary investors could be a nuisance, a large group could by filtered through a crowdfunding site and can offer more value than standard rich investors. This may be why Paul Graham accepted the crowd-sourced startup FundersClub into Ycombiantor. Startups may even start crowdfunding because of the product and marketing opportunities it will provide.

 

Lottery Ticket Investing

In a previous post, I listed a bunch of Startup Ideas, but I didn’t go into any details about them. In this post I will discuss one of the ideas – Lottery-ticket investing. I decided to start from one of the less realistic ideas, so I can move to more realistic ones in later posts. While writing this post, I realized there were even more issues than I initially thought.

Q: So why are you publishing it?
Well I thought it might still have some potential somewhere, and I can use a Q&A format to discuss its issues. And it touches on some questions in economics and psychology.

Lottery-Ticket Investing

Problem: People buy lottery tickets despite the poor odds, i.e. their negative expected return. They do this because they’re excited by the prospect of large winnings, and may not evaluate the odds correctly. But there should be some way to let them get tickets that offer a large prize, but still have an overall positive return.

Solution: Create an Investment Lottery: Invest the lottery ticket money in stocks, which historically have a strong positive return. Use a investing method with high-voltaility so there is a chance of large payouts.

Q: But how would you distribute the money?
One way would be to have an actual lottery at the end of the investment period and give the money to specific winners. However, this is too similar to a regular lottery, so the state governments wouldn’t allow it. Instead, one could give the actual returns of each ticket to the buyer. This way people who get or pick the right tickets can win big.

Q: So you’re basically just selling people stocks.
Yes, these tickets would let people easily invest small sums in a high-risk but high-reward manner.

Q: That sounds pretty boring.
It’s true that people are motivated to buy because of the hope of getting a huge prize, but people also buy tickets for smaller prizes. So one would need to examine where the cut-off would be. For example, people might be willing to pay $10 for a ticket that could potentially win $1000. If they here about one winner who won a huge prize, they might get excited enough by that possibility, even if it rarely happens.

Q: But how would you ever get 100x returns on investments in a short time-span?
There are a number of possibilites that one could explore. Perhaps there’s some way to do it with margin-investing, or with some variety of that. For example, the lottery stock tickets could insure other investors against losses, so the ticket-holders take larger losses or bigger gains if the stock has a large change. This will let the ticket-holders magnify their risk and provide insurance to safe investors.

Q: That doesn’t sound like a very good idea, and people can insure against losses without any lottery involved, e.g. by buying put options.
OK, so that idea might have some flaws. But there are risky investments that one could find, such as certain junk bonds. In addition, it will soon be legal for ordinary people to invest in small companies. They could serve as a very-high risk investment that could have extremely good returns. By making it easy for people to buy “Investing Tickets”, they can be encouraged to invest in a system that has good overall returns instead of losing so much money in the lottery. While they might not make it rich this way, they’ll have better long-term odds than in the lotto.

Startup Ideas

Paul Graham recently wrote a post about How to Get Startup Ideas, so I figured I’d write about a couple of startup ideas. This post list some of them in a couple of words, and later I’ll pick a few to write about in more detail.

Education & Content:
This is an area that many are working on to change (finally), but there’s still a lot that can be done.

  • Platform for creating interactive educational content.
  • New platform for publishing general content
  • Bootcamps for learning technical topics
  • Programming for the masses

Replacing Intermediaries:
Before the internet, it was necessary to have various intermediaries involved in transactions. The internet has changed that for many things (e.g. buying airline tickets), but some areas remain stubborn to change (e.g. cars or houses). There are various ways certain industries can be brought up-to-date with the internet.

Better Search
Everything is search. It’s not what you know, but what you can search for that counts.

  • A Better meta-search?
  • Better Website searches
  • Integrating search and actions within applications
  • Tracking everything you read or learn for later ‘recall’

Ecommerce
The Internet has changed how we buy things, but made everything more complex. People need help getting what’s best for them at the best price.

  • Finding the best deals quickly
  • Reliable data-based reviews
  • Chipping away at Craigslist…
Miscellaneous:
  • Crowd-sourced startups
  • Alternative Wikipedia
  • Lottery-ticket Investing
  • Computer-aided productivity

YCombinator Demo Day and Deadline

Ycombinator just had their demo day where 66 startups graduated the program and pitched to investors. In addition, tomorrow is the last day to apply for their summer cycle. Some interesting ones from current batch:

Crowdtilt: Kickstarter for raising money from friends.

Givespark: Kickstarter for celebrities to raise money for charity. Started by 4 students from Yeshiva University, including S. Laks. Short article about it on VentureBeat.

AnyVivo - They sell jellyfish online. Yes, jellyfish. They dominate the online jellyfish market.

ark.com - Thye’re supposed to be a good people search.

flutter.io - Control your computer using hand gestures.

icracked.com - Fix your broken iStuff.

For more info, see some of the posts on TechCrunch.

Why Governments Don’t Get Startups « Steve Blank

To date, Israel is only country that has engineered a successful entrepreneurship cluster from the ground up. It’s Yozma program kick-started a private venture capital industry with government funds, (emulating the U.S. lesson of using SBIC funds.), but then the government got out of the way.

In addition, the Israeli government originally funded 23 early stage incubators but turned them over to the VC’s to own and manage. They’re run by business professionals (not real-estate managers looking to rent out excess office space) and entry is not for life-style entrepreneurs, but is a bootcamp for VC funding.

Government and private enterprise don’t generally go well together, but Israel managed to get venture capital flowing by gathering the money and then getting out of the way.