Product Architecture
The role of the architecture in the plan

Homework due for today

Legend: : Participation | : Early | : PDF | : Team | : Zipped

  • Study and read up on the Nest Thremostat. The purpose of this homework is for you to practice applying what we have been learning about user experience to a product that you don’t know yet.

    Look for articles describing the user interface of the device and play with the demos on their site. You will find videos that describe the installation and the use of the NEST. You might also find articles that either complain or compliment the user interface of the NEST. What do you think they have done right, and what have they not done great? Make sure you refer back to the UX principles we’ve talked about or that you can find on the web. Don’t just list the features or that you think the NEST is cool, but be specific: “There are no affordances to explain to the user that they have to twist the ring” as an example (although I don’t know if that is or isn’t a fair point :)

    Deliverable: Write a post giving your assessment of the Nest User Experience. What is good and what might be better in their user experience, and what do you base your opinion on?

  • Meet with your team for 1-2 hours.
    • Do a more detailed and complete iteration of your User Experience flow, including paper prototypes and the UX flow itself. Document and/or revise your user experience flow. Make paper prototypes of all the important screens. Prepare to do a usability test with it.
    • Have a wide ranging discussion about your hypotheses and what more testing you need to do. Refer especially to my guidelines from a week ago about how to improve all the projects:
      • Think bigger. You will need to make a case that the product will be a viable business.
      • Be Serious. Your work is evaluated not just on whether you follow the steps or the format but based on whether you are being realistic and intellectually honest about your proposal. Would you actually pitch this to an Angel?
      • Get Out. Everyone needs to get out of the building more. Go beyond your friends. Talk to strangers!
    • Pivot. If you need to. Real startups pivot if the evidence is not coming in. Zoom out pivot if your idea is too small. Zoom in if it’s too big. See Types of Pivots
    • Presentation. Professional, neat, readable etc.

    Make notes of changes and plans to incorporate into your Term Project Report.

Technology and Architectural tradeoffs

  • These form hypotheses like any other solution hypothesis
  • For example
    • Can it be built? (“the api is rich enough to allow this product to be built”)
    • How long will it take? (“the product can be built to release 1 in 3 months”)
    • Will it perform? (“the product will be able to support 10,000 users in the first release”)
    • Should we use Android or iPhone, etc. (“it is safe to ignore the iPhone platform”)
    • What would it cost to manufacture? (“The first 100 units can be manufactured for $10 per”)
    • … etc.
  • These kinds of hypotheses need to be answered from a technical/technologoical perspective
  • How would you test the hypothesis?
    • Check with some experts to corroborate your hypothesis
    • Show them your design concept
    • Build a prototype/experiment/mvp to validate that assumption specifically
  • For example distinguish between:
    • Customers will require that we support both iPhone and Android
    • Our architecture can work on iPhone and Android
    • Different questions, requiring different experiments to check
  • Common Fundamental Architectural and Technology questions
    • Scale: How do we support the required number of users
    • Deployment vehicle: Cloud, Web, Mobile or Device
    • Discussion: Did I leave any out?
  • What about the ‘secret sauce?’
    • Your app may or may not require some
    • You might consider it your competitive advantage and even patent it
    • Most of your work (80% overall) will not be advanced computer science or new invention
    • For a real commercial product, most of the work will be hard engineering

Disruptive Innovation: “The Innovators Dilemma”

  • Disruptive Innovation:
    • An innovation that creates a new market by applying a different set of values, which ultimately (and unexpectedly) overtakes an existing market (e.g., the lower-priced Ford Model T)
  • Sustaining Innovation:
    • An innovation that does not affect existing markets. It may be either:
      • Evolutionary: An innovation that improves a product in an existing market in ways that customers are expecting (e.g., fuel injection)
      • Revolutionary (discontinuous, radical) An innovation that is unexpected, but nevertheless does not affect existing markets (e.g., the automobile)
  • The Dillemma:
    • When an innovation in technology changes it in a way that takes it from a specialized, expensive, niche market applicability, to a price and performance point where it can be broadly applied
    • The Innovators Dilemma: Should you embrace or ignore a new technology to address your existing business?
Innovator’s Dilemma Scenario
  • A new technology comes around which solves an existing ‘problem’ in a way that is not advantageous to the existing major users/customers/revenue providers
  • Established players are not in a position to capitalize on them because this is not what their existing customers are demanding. In fact it would be negative.
  • A new player may be able to identify a market in which the new technology’s drawbacks are actually somehow advantages. It goes after that market, all the while perfecting the technology getting it more and more ready for the larger market
  • When the time is right, the new player if they bet right may be able to go after the larger market, but the established player finds itself behind in the new technology and is blown out of the water.
History:
References

Next Class