Posts Tagged ‘requirements’

Latent requirements

November 24, 2015

When we design innovative solutions we often have to deal with two types of end-user requirements:

Obvious (explicit) requirements: clearly articulated improvements, amendments or extensions. For example, a faster horse, a cheaper car, more memory, more screens, louder speakers, and so on.

Latent requirements: unmet needs that people find difficult to express, write down or articulate.

Most people, when invited to contribute to the “innovation” of a product or service, end up simply describing an evolution of something familiar – their contribution to the process is limited by what they know. A conversation about the “possible” is difficult enough; and a structured conversation about the “impossible” is, well, nearly impossible. Researchers, designers and other “proxies” intervene to develop an understanding of what people really need. It is this understanding that drives innovation; not the users themselves.

http://blog.tobiasandtobias.com/2014/04/is-it-time-to-put-henrys-horses-out-to-grass/

Customer roles in B2B

September 16, 2015

Profiles of customers within an organisation vary according to sector and size of organisation but typically include the following

  • Influencers
  • Recommenders
  • Economic Buyers
  • Descision makers (typically sit within organisation)
  • End users
  • Saboteurs

Osterwalder et.al. 2014: p.50

Capabilities

February 19, 2012

Capabilities can be defined as combinations of people, process and technology

Empathy Map

November 16, 2011

What does she think and feel?

  • What really counts
  • major preoccupations
  • worries & aspirations

What does she see?

  • environment
  • friends
  • what the market offers

What does she say and do?

  • attitude in public
  • appearance
  • behaviour toward others

What does she hear?

  • what friends say
  • what boss says
  • what influencers say

Summary:

Pain

  • fears
  • frustrations
  • obstacles

Gain

  • wants/needs
  • measures of success

Based on a tool developed by XPLANE; described in: Osterwalder, A. & Pigneur, Y.: Business Model Generation; Hoboken, NJ:2010. pages 130

Customer-centric business model design

November 16, 2011
  • What job)s) do(es) our customer need to get done and how can we help? What are our customer’s aspiratins and how can ewe help him live up to them?
  • How do our customers prefer to be addressed? How do we, as an enterprise best fit into their routines?
  • What relationship do our customers expect us to establish with them?
  • For what value(s) are customers truly willing to pay?

Osterwalder, A. & Pigneur, Y.: Business Model Generation; Hoboken, NJ:2010. pages 129

Business Model Strawman

November 16, 2011

The 9 building blocks of a business model

  • Customer segments – An organisation serves one or several customer segments
  • Value Propositions – It seeks to solve customer problems and satisfy customer needs with value propositions
  • Channels – Value propostions are delivered to customers through communication, distribution, and sales Channels
  • Customer Relationships – Customer erlationshipsare established and maintained with each Customer Sefgment
  • Revenue Streams – Revenue Streams result from value propositions successfully offered to customers.
  • Key resources – Key resources are the assets required to offer and deliver the previously described elements …
  • Key Activities – … by performing a number of key activities
  • Key Partnerships – Some activities are outsourced and some resources are acquired outside the enterprise
  • Cost Structure – The business modelel ements result in the cost structure

Osterwalder, A. & Pigneur, Y.: Business Model Generation; Hoboken, NJ:2010. pages 16/17

For printable canvas to be used in WS etc. see www.businessmodelgeneration.com

CCIR brand personality metric

November 15, 2011

Centre for Communication Interface Research (CCIR) is part of the School of Engineering at the University of Edinburgh

CCIR’s brand personality metric uses a proven questionnaire based on an extensive study of the salient attributes of brand personality from published academic and business literature and from previous experiment work in the area. The brand personality attributes assessed in CCIR’s metrics focus on customers’ organic perceptions and attitudes to new processes experienced in an experiment setting, addressing perceptions of brand personality for 24 attributes:

  • Modernity attributes: a brand that is forward thinking, modern, imaginative and stylish.
  • Enthusiasm attributes: a brand which appears confident and enthusiastic.
  • Personal attributes: a brand that is conscientious, welcoming, cheerful, caring, friendly, helpful, approachable, patient, sincere and genuine.
  • Competency attributes: a brand that is dependable, professional, consistent, meticulous, efficient, competent, trustworthy and security conscious.

Sales funnel

November 14, 2011

Specific steps or stages in a sales process vary from company to company but generally include the following elements:

  1. Initial contact
  2. Application of Initial Fit Criteria
  3. Sales lead
  4. Need identification
  5. Qualified prospect
  6. Proposal
  7. Negotiation
  8. Closing
  9. Deal Transaction

An alternate but similar series of steps is as follows:

  1. Prospecting/Initial contact
  2. Preapproach- planning the sale
  3. Approach
  4. Need assessment
  5. Presentation
  6. Meeting objections
  7. Gaining commitment
  8. Follow-up

Wikipedia

Requirement priorities

August 1, 2010
  • Non negiotiable
  • Preferred
  • TBD

Requirement analysis

July 26, 2010
  • business requirements; These requirements have their basis in strategic business goals for your product. Defining the business requirements for your product is primarily the responsibility of your organization’s business leaders and/or the product manager on your product team. Business requirements should answer these questions:
    • What is the product vision?
    • Are we solving the right problem?
    • What business goals must the product satisfy?
    • What is the product’s revenue model?
    • What is the timeline for the product’s release?
    • What are the time and budgetary constraints for the overall product development effort and, in particular, for your design effort?
  • market requirements; Your organization’s product strategy and business goals and your product’s place in the competitive marketplace dictate what capabilities, features, and qualities your product must have. Defining the market requirements for your product is primarily the responsibility of the product manager for your product. Market requirements should answer these questions:
    • What is the product’s essential functionality? What features must it include to compete in the marketplace?
    • What other possible features might the product include? What are their priorities?
    • What differentiates the product from other similar products in the marketplace?
    • For an existing product, what features have customers requested?
    • What information does your organization want to communicate to users?
    • What information does your organization want to obtain from users?
    • What technologies must the product employ? With what other products must it be compatible?
    • What standards of performance must the product achieve?
    • If the product is a software product, for what platforms is the product to be developed?
    • Is the product a standalone product or part of a product suite?
    • What user assistance or documentation does the product require?
    • What training and technical support will the product require?
    • For what international markets is the product to be developed?
  • user requirements; These requirements have their basis in your user research, data analysis, user modeling, and task analysis. If your primary responsibility is the interaction design for your product, you should work collaboratively with the product manager on your product team to define user requirements for your product, basing them on a deep understanding of your primary and secondary target users; goals, desires, needs, and tasks; and for an existing product, your awareness of the pain points users are experiencing with your product. Satisfying these requirements is essential to developing a product that can succeed in the marketplace. Ensure that your product manager always states user requirements in terms of capabilities, not design solutions. User requirements should answer these questions:
    • What capabilities and features must your product provide to satisfy your target users?
    • What must your target users be able to do using your product? What workflows and tasks must your product support for your target users to be able to accomplish their goals efficiently?
    • What needs, desires, and preferences must your product satisfy for your target users? What qualities must your product have?
    • What information needs do your target users have? When do they need information? How should your product provide the information they need, when they need it?
    • What data must your product enable your target users to provide or create and save?
    • What kinds of data objects should your product let your target users manipulate?
    • Are there different user roles your product must accommodate?
    • Do your target users require your product to be customizable and/or personalizable?
    • What standard of usability must your product achieve?
    • For an existing product, what pain points does your product redesign need to address?
  • technical constraints; Because your design solutions must satisfy technical constraints, they limit the possible design solutions for your product. The product manager and/or system architect on your product team are responsible for defining these technical constraints. Be sure to find out what technical constraints you must consider when designing your product. These technical constraints may cover the following:
    • database constraints
    • technology constraints and requirements
    • performance requirements
    • operational requirements
    • maintainability requirements
    • reliability requirements
    • safety requirements

From Pabini Gabriel-Petit: Design Is a Process, Not a Methodology