Final Flashcards
Given the nature of the Vasa project, how/where might an Agile approach have been used? Or, is an Agile approach even a good (or useful) idea for the Vasa? Why? Why not? Explain.
Agile would have not been used for the Vasa because it was an oversized project that was complicated by many issues.
Think about how well a risk management approach could have worked for the Vasa (or if it could have worked). Be sure to again consider the factors that helped influence the approach(es) (actually) used and the decisions made.
Vasa syndrome is a term used in management which is inspired by that disastrous event and describes a collection of risk factors, including problems with goal-setting, team communication and handling unexpected changes in plans, which could spell doom for any project.
What is the difference, if anything, in the amount of responsibility vs. authority that the Master Shipwright had on the project? Explain. How might this translate into an Agile Product environment? Explain.
Master Shipwright Henrik Hybertson was responsible for designing and building the Vasa. Since, there was no scientific theory of vessel design, no drawings or schematics, or stability available. He made no mathematical calculations which was crucial to determine a ship’s center of gravity, its center of displacement volume, its form stability, or its weight stability. Everything else was up to the craftsmanship, professional skill, and experience of the master shipbuilder. Agile product environment probably would not have worked.
When should you use (or not use) Agile?
Use Agile: Customer preferences and solution options change frequently; Close collaboration and rapid feedback are feasible. Customers know better what they want as the process progresses; Problems are complex, solutions are unknown, and the scope isn’t clearly defined. Product specifications may change. Creative breakthroughs and time to market are important. Cross-functional collaboration is vital; Incremental developments have value, and customers can use them. Work can be broken into parts and conducted in rapid, iterative cycles. Late changes are manageable; and They provide valuable learning.
Not use Agile: Market conditions are stable and predictable; Requirements are clear at the outset and will remain stable. Customers are unavailable for constant collaboration; Similar work has been done before, and innovators believe the solutions are clear. Detailed specifications and work plans can be forecast with confidence and should be adhered to. Problems can be solved sequentially in functional silos; Customers cannot start testing parts of the product until everything is complete. Late changes are expensive or impossible; and the impact of interim mistakes may be catastrophic.
What is “Shuhari” (or “ShuHaRi”)? Explain. What is it about (or for)? How might this help us when thinking about Agile Product development?
Shuhari is a process that Japanese martial arts students studying aikido. In the shu state they study proven disciplines. Once they’ve mastered those, they enter the ha state, where they branch out and begin to modify traditional forms. Eventually they advance to ri, where they have so thoroughly absorbed the laws and principles that they are free to improvise as they choose. This is relates to Agile product development as Mastering agile innovation is similar. Before beginning to modify or customize agile, a person or team will benefit from practicing the widely used methodologies that have delivered success in thousands of companies. Over time, experienced practitioners should be permitted to customize agile practices and many companies are still using the practice even though new technology minimized input time and allow the information to be shared simultaneously in multiple locations.
When did the Agile approach come into existence? Is there a ‘birthday?’
It came into existence in 2001 at Snowbird, Utah
Are there examples of Agile before Agile was officially created?
Rapid Application Development (RAD) [1991]
Rational Unified Process (RUP) [1994]
Extreme Programming (XP) [1996]
Feature-Driven Development [1997].
Scrum, probably the best-known Agile approach, originated in 1995.
Where did the idea for SCRUM come from (i.e., for the name)? And the overall concept, too?
This idea came from Rugby where it was a formation of players. SCRUM uses small teams to produce small pieces of deliverable software using sprints, or up to 30-day intervals (i.e., 4 weeks), to achieve an appointed goal … in fact, the sprints are often one week or two weeks in length, with a two-week length (probably) being the most common.
What is meant by the concept of “Product Discovery” when talking about an Agile Product? How is Product Discovery done?
Is discovering products as we continue along with product development
Agile Manifesto – What is this? What is/was its purpose and/or main points? When was it developed, i.e., when was it first written? Why? For what purpose? What are the main themes or ideas for the ‘Manifesto?’ How does this contribute to Agile development?
In 2001, 17 software developers met at a resort in Snowbird, Utah, to discuss (lightweight development) issues related to software development. These developers have sometimes been called ‘anarchists’ for their attempt to ‘overthrow’ more traditional, predictive, heavyweight approaches.
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
• Individuals and interactions are preferred over processes and tools
• Working software is preferred over comprehensive documentation
• Customer collaboration is preferred over contract negotiation
• Responding to change is preferred over following a plan
DevOps is often described or categorized as an Agile approach. What is DevOps? How does it work? How is it different from Agile, or is it really just Agile with a different diagrammatic representation? How is it different from Scrum (or Agile)?
It is breaking down the barriers between the development and the operations team(s), a set of practices intended to reduce the time between omitting a change to a system and the change being placed into normal production, while ensuring high quality. It uses Agile and other development processes and methods with a different diagrammatic representation.
Triple Constraint – components and relationships … what does the concept imply? How (or where) does ‘quality’ fit within this framework? An especially important issue – Is the Triple Constraint relevant for Agile development?
Also called the “Iron Triangle”. It’s Balancing the three key, interrelated aspects of time, cost, and scope. The project manager is instrumental to the successful completion to any project.
Project Lifecycle – basic phases … different types, their focus & intent in an Agile environment … how is this different from the Waterfall (i.e., traditional) approach?
Predictive Life Cycle (Waterfall) plans organized around tasks, has a defined and fixed scope, a detailed project schedule, a detailed cost plan, and a plan for overall project risk.
Agile’s plans are feature based, the scope often not known, focuses on short cycles, uses high-level forecasts, and a plan for risk by iteration.
How do we do Prioritization ‘things’ in Agile?
It says the best way to achieve this is to create a ranked list of priorities. Ranked priority means if you have a list of 10 tasks, each task gets a number between 1 and 10. Two tasks can’t both be priority one. One must be priority one, and the other priority two.
Does an Agile approach help us in assessing and reducing project risk?
Using an agile approach massively reduces risk. It is true that the agile approach reduces some risks, such as the possibility of developing products that the market does not need. Used correctly and constantly, communication and iteration make it nearly impossible to miss the market.
What did ‘Ralph’ (Jocham, from Scrum.org) mean when he talked about the idea of a Project as being a ‘container?’
For all the activities laid out in sequence where we plan, analyze, design, implement, test, and release the product.
How did Nokia succeed in its cell phone project(s), yet fail as a Product? Explain. Think about how/where an Agile approach might have helped.
They used a competitive advantage through its highly valued products, services and innovations. It includes a pervasive bureaucracy leading to an inability to act, destructive internal competition and the failure to realize the importance of lifestyle products like the iPhone.
What are the primary differences between a Waterfall approach and an Agile approach to project management and/or product management?
Project Management relates to Waterfall project methodology is a model in which every stage of a product’s life cycle takes place in sequence. The progress flows steadily downwards through these phases like a waterfall.
Product Management relates to Agile software development methodology is the model that proposes a sequential, linear and iterative approach.
What are the differences in emphasis in Project Management and Product Management?
Project Management • A focus on output • Success measured by time/scope/budget • Fixed scope and deliverables • Limited ability to adapt • Fixed funding based on scope • A (generally) stagnant culture • Waterfall development & delivery
Product Management •A focus on outcome •Success measured by customer value •Scope constantly evolves •Facilitates adaptation •Funding set for duration and capacity •A learning culture •Agile development & delivery
How is the Agile approach different from a Waterfall (or Traditional) approach?
- In Waterfall model software development, the process is divided into different phases. Agile proposes to segregate the development lifecycle into sprints.
- In Waterfall, development process should be implemented as one single project. Then this project is divided into phases. Agile contains a set of different projects that are the iterations of the different stages. They are focused on improving the quality and feedbacks from users.
- Waterfall software development model is structured and often rigid. Often project managers prefer Agile as a more flexible model.
- According to the iterative Waterfall model in software engineering, all the project phases are completed at a time. In Agile they follow an iterative development approach. So some of the phases can appear more than once.
- There is no chance to change the requirements once the Waterfall project development starts. Agile is more flexible and allows changes in the project development requirements. Even after the planning has been completed.
- One more difference between Waterfall and Agile is their individual approach towards testing and quality. According to Agile, testing is usually performed concurrently with programming. In Waterfall, testing phase comes after the build phase.
- Waterfall approach does not require the participation of customers, as it is an internal process. However, Agile methodology focuses on clients satisfaction and involves them to participate throughout the development phase.
- Waterfall iterative model is good for projects with clearly defined requirements and without expected changes. Agile allows changing and evolving the requirements.
With Agile, do all of the Product have to be digital products? Do they have to have some form of digital components or features?
Yes and No.
Yes, your adding a new piece that exists in a existing product.
No because your adding something that exists
Review the Owlet Baby monitor material
- What is the product being developed?
- What were their starting assumptions?
- What did they do as part of the development process?
- What did they do?
- What steps did they take?
- What problems/issues/unexpected results did they encounter?
- How did they respond?
- What did they learn?
- What surprised them?
- Why was this important?
- Wireless socket simulator
- Put the technology into a ankle socket on the baby and send the information wirelessly to a relay station alerting the parents as well putting the information on a smartphone.
- Use new technology until the hospitals told them it has to clinic approved technology.
- They did extensive testing and figuring out the right size as the baby would grow within a year. Figure out the market risk which was easy and technology risk which is hard.
- They got information from parents, they surveys, build the website, permit with FDA
- They unexpectedly got problems with the FDA as they have to file a permit, misunderstanding what the price they would pay for their product.
- They responded by filling a permit with the FDA and getting more information with how the product will be priced and getting the product market segmented.
- The user is not always their customer, they did surveys which they changed how they would price their product, segment their customers.
- When they proposed their product, they had an overwhelming positive response from their potential customers. They build a website and a video on the website that was leaked out before it was introduced, they need FDA compliance for their product.
- The company was wanting to develop innovative health products but has run into troubles from not being approved by the FDA to recalling their products.
What is the idea of “Product Discovery?” How does this fit within an Agile approach?
Is a process that helps product teams refine their ideas by deeply understanding real user problems and then landing on the best way to solve them. Product discovery focuses on the customer and how product teams will quickly and consistently produce better designed and high performing products. The human centred approach to product discovery leads to increased problem-solution fit hence higher customer value.
What are the main ‘pieces’ of Scrum? What is each for? Is there a sequence in which they are done, Why or why not?
Sprint planning -> Daily scrum -> Backlog refinement -> Sprint review -> Sprint retrospective -> Customer ready product increment -> Incremental product release
It’s done in order
What are the main roles (for people) in Scrum? What does each person/role do? How are these roles different from the Traditional/Waterfall approach, or are they different?
- Scrum uses small teams to produce small pieces of deliverable software using sprints, or up to 30-day intervals (i.e., 4 weeks), to achieve an appointed goal … in fact, the sprints are often one week or two weeks in length, with a two-week length (probably) being the most common
- Under this methodology, (the typical approach is) each day begins or ends with a stand-up meeting of the entire team to share what’s been done, problems encountered, how they were addressed, and what is next … these help w/ coordination for monitoring and controlling the development effort
What are the four variables that should be assessed to determine whether it is worthwhile to start or continue a Product Development process? What is the focus/emphasis for each one?
Valuable: Will customers buy it or users choose to use it?
Usable: Can customers/users figure out how to use it?
Feasible: Can this be built? Can we build it with the time, skills, and technology that we have?
Viable: Can this solution work for the purposes for which it has been built?
How is a ‘Scrum Master’ different from a ‘Product Manager,’ or are they really the same thing?
Scrum Master
‒ Act as coaches for the team on Scrum practices
‒ Servant leader focused on removing impediments
‒ Tracks team progress
Project Manager
‒ Serves as the “Voice of the Product”
‒ Ensures product meets customer needs
‒ Full responsibility and ownership over product deliverable
‒ Intersection of business, technology, and user experience
‒ Looks long-term to assess market changes
‒ Adjusts scope as needed with Product Owner to prioritize key features
Explain the statement: “… all of the roles revolve around the delivery team to help them do their best work at their best pace …” In what type of approach is this description relevant/accurate (e.g., Waterfall, Agile, Scrum, XP, etc.)?
Waterfall depicts how the schedule for the project goes while agile gets the product developed.
Explain the purpose of a Product Canvas?
Is a planning tool designed to help build products that have a great user experience through a focus on feature development.
What are the main components of a Product Canvas and What is each component for?
- Vision: Why are you creating your product? In other words, what is the founding inspiration for your idea? This should typically be one relatively short statement or sentence … or use a template.
- Name of the product
- Goal is the reason creating the project
- Metrics is the measures to determine if the goal has been met.
- Target group is the user and the customers with their needs. Personas are a great way to describe the target group.
- Big picture is the desired user experience: the user journeys, the product functionality, the visual design, and the nonfunctional properties. Epics, scenarios, storyboards, workflows, design sketches, mock-ups, and constraint stories are helpful techniques.
- Product details is the goal of the next iteration with specific actionable items to reach the goal. The items are ordered from one to another and may be captured as detailed user stories.
In the Product Canvas, what is the “Target Group?”
It is the user and the customers with their needs. Personas are a great way to describe the target group.
Why have a Product Vision? You might find it useful to review the John Deere Farm Forward 2.0 Vision (from the embedded video in the PowerPoint slides)
A Product Vision is a prerequisite for strategy … your Product Vision should not be a plan that shows you how to reach your goal … it should allow you to pivot as you learn and build while staying consistent with your vision … you don’t know exactly where you are going to be at the end of the product’s development … you will figure that out as you go, and you’’ adjust to new market conditions, to your customers, the environment may change … those things (and others) will cause you to adjust …
What is meant by the statement by the Cheshire Cat from the “Alice’s Adventures in Wonderland” excerpt: “If you don’t know where you are going, any road will take you there?”
How is this quote relate for Agile?
Is creating the vision for your product in any way to attract customers and is a prerequisite for strategy.
Briefly describe two ways to craft a Vision statement. How are they similar or Different? What might be the benefits of each? Disadvantages/Limitations? Which do you think you would like to use, and why
Fairy Tale Approach is a system of guiding the client to achieve specified outcomes in a set order
Generic Approach is purports that an individual-focused approach - emphasizing individuals’ unique, diverse intrapsychic and interpersonal processes and needs - can always be initiated later on if necessary, based on a careful screening and referral process.
Within the larger Agile framework and the Scrum approach, in particular, where in the Scrum model (i.e., Sprint) are all of the tasks (that we’ve been doing in class through the various assignments) actually being done? For example, where is the Vision being created? The Product Canvas being done? The Metrics, Target Group, and Big Picture being identified and developed? Where are the User Tasks, the Features, and the User Stories (+ Acceptance Criteria) being developed? Story Points? Prototyping? User Testing? UX (User Experience)??”etc. Where does all of this fit?
Your figuring what those items and sequences are. You have a goal in mind but you don’t know what the product will look like. There are things we can do in a perfect or different way. On going evolution of the project.
What is a Story Map? What is its purpose? What is its objective? What is the process? How is it built? How is one created? How is it used? How many layers are there (or should there be) in this tool/approach?
Is an approach to gain shared understanding of problem we are trying to solve. An approach to keep the objective (desired outcome) at the forefront.
1) List the actors (on the left)
2) Write the ending (on the right)
3) Words / Arrows in between
4) Keep it simple
5) Ask for help & feedback!
What is a Storyboard? What is its purpose? What is its objective? What is the process? How is it built? How is one created? How is it used? How many layers are there (or should there be) in this tool/approach?
Is a graphic organizer that provides the viewer with a high-level view of a project. In Agile software development, a storyboard can help developers quickly get a sense of what work still needs to be completed. As long as the team keeps the storyboard up to date, anyone can see what work has been completed, who’s working on what and what work is left to do. This not only provides the product owner with transparency, it also helps the team to visualize the sequence and interconnectedness of user stories. Storyboards can be physical or digital.
What is a Persona?
Is a fictional group that can function as a description for the Target Group, with attributes, such as: ‒ Name ‒ Job Title ‒ Age, Ethnicity, etc. ‒ Goals and Tasks ‒ Behaviors
What is a Feature?
Is a service or function of the product that delivers business value and fulfils the customer’s need. Each feature is broken down into several user stories, as it is usually too big to be worked on directly.
What is a User Story?
Is the smallest unit of work in an agile framework. It’s an end goal, not a feature, expressed from the software user’s perspective. A user story is an informal, general explanation of a software feature written from the perspective of the end user or customer.
What is an Epic?
Is a body of work that can be broken down into specific tasks (called user stories) based on the needs/requests of customers or end-users. Epics are an important practice for agile and DevOps teams. When adopting agile and DevOps, an epic serves to manage tasks.
What is a Prototype?
Is a early sample, model, or release of a product built to test a concept or process or to act as a thing to be replicated or learned from. Prototyping gives everyone on a team a single idea to work from and is a far more effective way to communicate a designer’s intent than a group of static screenshots.
How is a Persona used? Where do Personas come from, i.e., who makes/writes them?
Functions as a description for the Target Group, with attributes, such as:
‒ Name
‒ Job Title
‒ Age, Ethnicity, etc.
‒ Goals and Tasks
‒ Behaviors
Create Persona Profiles
‒ What fictional character(s) should be created to represent the target users?
‒ What are attributes of these?
Personas are synthesized from data collected from interviews with users. They are captured in 1–2-page descriptions that include behavioral patterns, goals, skills, attitudes, with a few fictional personal details to make the persona a realistic character.
How/ Where are the interview questions used? For what purpose? Are these all that there are? Where do they come from? Can you think of any additional interview questions you might want to ask?
They are used to get information from people and they ask certain questions about certain events or topics. The purpose is to get consumers aware of your product and see what feedback they provide to determine if any changes are needed.
What is the Product Backlog? What is its purpose? What is it made of, i.e., what does it contain? What questions are you trying to answer?
It’s a list of all of the features from user stories the product should contain. The list is refined overtime and we need to quickly get to MVP as possible. When we finish the product, we go to the backlog refinement and check any additional details needed to be added.
What is the “slicing value” that is discussed? What is the point that is being made here?
‒ The slices are often called Features
‒ This can serve as a way to prioritize and plan releases
What is a Backlog?
It’s a list of all of the features from user stories the product should contain. The list is refined overtime and we need to quickly get to MVP as possible. When we finish the product, we go to the backlog refinement and check any additional details needed to be added.
What is Backlog Refinement?
Is repirotixing the backlog for the next item may not be the top priority.
What are Product Backlog Items (PBIs)? What are the primary components of a PBI?
It should convey context needed for the team to deliver an outcome aligned with the value requested. PBIs are often in the form of user stories that include: ‒ Value Proposition ‒ Recipient of Value ‒ Action Needed ‒ Constraints ‒ Test Criteria
What is a Story Point? How does it work? What does a Story Point represent? How is the value determined? What are the benefits and/or Risks? What are the challenges in doing Story Points? Is there another way to do the same thing?
A unit of measure for expressing an estimate of the overall effort that will be required to fully implement a Product Backlog item (or any other piece of work)
‒ The actual point values do not really matter! … what matters is the relative values or relative weights that are assigned for all of the stories … for example:
• a story that is assigned a 2 should require twice as much effort as a story that is assigned a 1
• it should also be two-thirds of a story that is estimated as 3 story points
‒ A team’s estimate must include everything that can affect the effort, including:
• The amount of work to do
• The complexity of the work
• Any risk or uncertainty in doing the work
What are the three components that a Story Point value is supposed to represent? Where does “Effort” fit here?
Complexity
-Complexity should also be considered … and reflected in the estimate provided
‒Example: Think back to the earlier example of developing a web page with 100 trivial text fields with no interactions between them
•Now think about another web page also with 100 fields … some are date fields with calendar widgets that pop up; some are formatted text fields like phone numbers or Social Security numbers; other fields do checksum validations, as with credit card numbers
•This screen also requires interactions between fields… Example: If the user enters a Visa card, a three-digit CVV field is shown; if the user enters an American Express card, a four-digit CVV field is shown.
‒Even though there are still 100 fields on this screen, these fields are harder to implement… they’re more Complex, take more time, and there’s more chance the developer makes a mistake and has to go back and correct it
Risk and Uncertainty:
‒The amount of Risk and Uncertainty in a Product Backlog item should affect the story point estimate given to the item
‒Example: If a Product team is asked to estimate a Product Backlog item and the stakeholder (i.e., customer or user) asking for it is unclear about what will be needed, that Uncertainty should be reflected in the estimate
‒Example: If implementing a Feature involves changing a particular piece of old, brittle code that has no automated tests in place, that Risk should be reflected in the estimate
‒Complexity is based on both Risk and Uncertainty
Amount of Work: If there is more to do of something, the estimate of effort should be larger … Consider:
- A situation where two web pages are being developed. The first page has only one field and a label asking to enter a name; the second page has 100 fields that are also simply be filled with a bit of text
- The second page is no more complex… there are no interactions among the fields and each data field is nothing more than a bit of text… i.e., there’s no additional risk on the second example page. The only difference between these two pages is that there is more to do on the second page.
- The second page should be given more story points. But it probably shouldn’t get 100 times more points even though there are 100 times as many fields… After all, there are economies of scale and maybe making the second page is only 2 or 3 or 10 times as much effort as making the first page
Why are Prototypes used? What is/are the benefit(s) being sought from Prototyping?
It is a sample or first (or at least early) model of a product from which more copies are derived and improved upon. It is usually built as a model to test a product concept or
process or to act as an example for replication or learning. Benefits include:
1. Fast and effective communication of design ideas
2. Effective validation of design fit, form, and function
3. Greater design flexibility
4. The ability to run quickly through multiple design concepts and corrections
5. Fewer production design flaws and better end-products
What are the different types of Prototyping methods that are most often in use? Make sure you understand the differences and emphasis of each.
‒ Feasibility Prototypes – not typically used in Product Discovery
‒ Low-Fidelity User Prototypes – sketch or wireframe diagrams
‒ High-Fidelity User Prototypes – simulation that looks almost real (aka Functional, Functioning, or Working …)
‒ Live-Data Prototypes – limited implementation of product/system … Not scalable or shippable
‒ Hybrids – can be a blend of any of the others
Three additional types to note (… and they may overlap w/ the types listed above)
‒ Proof-of-Concept / Proof of Principle – essentially the same as Feasibility
‒ Selling – can be low- or high-fidelity … high-fidelity ‘works’ better at the selling
‒ Throwaway – similar to Feasibility and Proof-of-Concept
Why is Prototyping (potentially) so important?
- Fast and effective communication of design ideas
- Effective validation of design fit, form, and function
- Greater design flexibility
- The ability to run quickly through multiple design
concepts and corrections - Fewer production design flaws and better end-
products
What are some examples of the use of Prototyping that we encountered in class? What types of Prototyping were used? Also consider our viewing and discussion of the video clip on McDonalds and the Kiva robotic system (in relation to prototyping)
- Walt Disney Concert Hall, Los Angeles, CA Designed by Frank Gehry
- Dyson’s Cyclonic Separation (i.e., bag-less) Vacuum Cleaner
- IPhone
- In the movie “The Founder”, McDonald’s did multiple prototypes on a shuffleboard surface with chalk and after revising the order process to remain fast and quick food. They found their layout for future restaurants to build upon.
- Kiva robotic system was made by a company called Kiva Systems which can lift a shelf with items weighing around 40 to 60 pounds and move it from one end of the warehouse to the other. Amazon acquired the company in 2011.
Explain the idea behind User Testing? Why do it? (Can’t we sufficiently test our products ourselves?) What is/are the benefit(s)? How might Kickstarter be used as a part of User Testing? What are some other User Testing approaches that are commonly used? Who are the primary participants in User Testing?
It is what the Designer Creates and What the User Expects. With the goal of a much greater overlap between these two ‘perspectives’ than what is shown / implied here!
‒ Key Participants – Product Owner, User Experience Designer, Target Customers/Users
‒ Techniques – There are several common techniques in use …
• Landing Page & Fake Door
• Kickstarter / Crowdfunding
• A/B Testing
• Contextual interviews, focus groups, and surveys
• Research (market, competition)
• Observation / Shadowing
‒ Output – User feedback to assess the value and usability of the product
What is a Landing Page?
Is a stand-alone web page created specifically for a marketing or advertising campaign, often with a Call-to-Action (CTA) component… It’s where a visitor ‘lands’ after they click on a link (in an email, or ads from Google, Bing, YouTube, Facebook, Instagram, Twitter, or similar places on the web) … typically contains on a single (or very few) action(s) available on the page.
What is A/B testing?
aka ‘Split Testing’, it is a randomized experimentation process where two (or more) versions of a variable (e.g., web page, page layout, color schemes, shapes of elements or icons, etc.) are shown to different segments of website visitors at the same time to determine which version generates the greatest impact and drives business metrics.
What is a A Fake Door? What can you learn from a Fake Door approach? How does a Fake Door work? Is it ethical?
Is an easy, yet very powerful approach to measure interest in a product (or a new feature) without actually coding and implementing the product itself … Steps:
- Create a landing page where you explain the purpose of the service. It can be a fully featured landing page, or it can be a short “beta” version
- You drive traffic to this landing page. The best way to do so is using paid advertisements. (e.g., Facebook, LinkedIn, Twitter, or Reddit ads)
(As discussed in class,) what was the original conception of the first iPhone? What was/were the killer app(s) that were thought of for this device? What happened with that original conception?
- Project timeline: Nov 2004 – June 2007
- Original goal was just to make ‘a really cool phone’ that worked well …
- “What’s the killer app? The killer app is making phone calls. It’s amazing how hard it is to make calls on most phones.” Steve Jobs, Keynote Address
- It would fit comfortably in your hand and in your pocket
- Make ‘good’ phones calls (that would not get dropped)
- Mostly an iTunes phone
- Many designers/engineers also saw it as an opportunity to build a new kind of mobile computer … but Jobs didn’t (at least not initially)
- Even the larger screens really did not come along until just after Jobs’ death (late 2011) from pancreatic cancer
MVP Concept – What is an MVP? What is its purpose?
MVP stands for Minimum Value Product and is to is the first version of a product that can be released to users
‒ Provides core functionality without any addition features
‒ A way to see how customers ‘feel’ about a product or idea
‒ Based on customer’s responses the feedback can be used to develop the next iteration (i.e., version) of the product
What does OKR stand for and purpose?
Is business goal is a measurement of progress and can be written in the form of Objectives & Key Results (e.g., OKRs) to create and assess alignment between the strategy and the execution throughout an entire organization. The idea came from Intel
Objective – What you want to achieve
‒ Significant, concrete, and action-oriented
Key Results – How you know if you’ve met your objective
‒ 3 ways to measure + 1
‒ Helps to benchmark and monitor progress
Primary characteristics of OKR’s? How is this concept used? When and where is it used?
Objective – (Can be) Qualitative and (should be) Inspirational (i.e., be audacious) – Get people to jump out of bed with excitement. Key Result is Quantitative.
Time Bound – Specification; Doable in a month, quarter, 8 sprints, etc.
Actionable – The objective has to be ‘yours’ to achieve … Dependencies can make this a challenge!
Simply stated – should fit on one line
What is a good/reasonable number for OKRs? (How many is probably too few, and how many is probably too many?) –Do note the overlap in guidance for the next two items
12 Key Results more or less means your team has only 1 week to deliver a Key Result. Any more than 12 and you risk losing focus. We have seen that 12 is the maximum a team is able to achieve consistently.
What is an Objective? Purpose? Primary characteristics?
Objective is what you want to achieve‒ Significant, concrete, and action-oriented. It (Can be) Qualitative and (should be) Inspirational (i.e., be audacious) – Get people to jump out of bed with excitement. Key Result is Quantitative
What is a good/reasonable number for OKRs in Objective? (How many is probably too few, and how many is probably too many?)
One
What is a Key Result? Purpose? Primary characteristics?
Key Results – How you know if you’ve met your objective
‒ 3 ways to measure + 1
‒ Helps to benchmark and monitor progress
Time Bound – Specification; Doable in a month, quarter, 8 sprints, etc.
Actionable – The objective has to be ‘yours’ to achieve … Dependencies can make this a challenge!
Simply stated – should fit on one line
What is a good/reasonable number for OKRs in a key result? (How many is probably too few, and how many is probably too many?)
Two to five key results
What are the OKR Do’s and Don’ts?
Do’s:
‒ Make your OKRs visible
‒ Ensure alignment with management and the team
‒ Make sure there is stretch in the OKR
‒ Focus on the outcome
Don’ts:
‒Use OKRs as a task list
‒Go overboard with the # of OKRs (3-5 is generally enough!)
‒Cascade from the top of the organization down
‒‘Sandbag’ so you can hit your OKRs each quarter
‒Focus on the output
‒Write your OKR to encompass everything your team works on pendencies across teams
