Curso Job-to-be-done / The customer centered innovation map study notes part 2
Reference meeting
- Scope: Jobs-to-be-done course
- Study notes by Marcio S Galli
- Status: Working draft
- Reference: a05-710.1 — minisites — marcio — working drafts 2d06fec8-a5fc-45f3-bb1d-cde7fed2aeb5 Quinta-feira, 26 de dezembro⋅5:00 até 7:00pm
- Episode 3
- Next 4
- Prior 2
Material studied
- Date of article: may of 2008
- Harvard Business Review
- Title: The Customer-centered Innovation Map
- Authors: Lance Bettencourt, Anthony Ulwick
- Referenced book: What Customers Want
a05-710.1 — minisites — marcio — working drafts 2d06fec8-a5fc-45f3-bb1d-cde7fed2aeb5
Job mapping - relating to a "customer task" and "steps" involved representing what they are trying to get done
- The idea of "job mapping" relates to the identification of a task that a customer needs to do, and breaking down steps for what are they "trying to get done". p.2.
Anatomy (aspects?) of a Customer Job
Jobs are processes — a job have a beginning, middle and end and it consists of steps; the steps are sequential, at least in the scope of this methodology, and each step will depend on inputs and produce outputs; The rearrangement of the steps, their order, or their method of processing is where value creation can emerge;
The job universal structure — steps are phases: defining, identifying/locating; preparing (components and the physical environment), confirming (check), executing, monitoring (results (output?) and the environment), modifying, and concluding. Depending on the goal job/task, some of the steps can be more apparent, and of course potential solutions may have to do with changing the role of steps in the flow;
Jobs are not solutions — when moving the focal point to the job, not looking at specific way, or the status quo in terms of the way they are doing; innovation designers are in a better position, because they can reconsider new alternatives, they may end up creating another "timeline" for executing the role job, for example with a different value generated by a new arrangement of steps in the process; thus they can end up encountering a "blue ocean" arrangement.
Creating a job map
Define — This is the planning phase that a given job may require. The definition of objectives are present at this stage; the assessment of the necessary resources; the strategy or the approach. p.4. New solutions may look at this space to improve the management and planning step for a given job.
Locate — For a job to be done, a locating (items or resources or inputs) phase happens. This aspect may be perceived by actions that may involve queries (this is Marcio's own observation). Inputs can be tangible, such as the the means to buy grains for a beer production (marcio's guess example) or can be intangible, such as assets or business requirements to be in a software development process by a developer. p.4
Prepare — Relates to the phase when the user/consumer is organizing the materials, inputs, and the environment in order to move forward. An example, in a brew making scenario, it could relate to the moving of bags of grains, the removal of the grains from the bag, perhaps water warming etc.
Confirm — this step may relate to checking before launching; it may relate to quality as well. It accounts materials, inputs, and the conditions for the working environment. It may involve data or attributes, tangible or not. The confirmation, for acceptance to the next step, is critical for the conditions that the, for example, going towards the next step (without confirmation) puts the job at risk. Such as mission critical systems.
Execute — Generally the heart of the matter – it's usually the visible steps. It seems to be a bit confused, nowadays specially when we think about online information-based (intangible) solutions, this very attempt to identity the execution steps. Exactly because today more and more systems are being part of other workflow systems, thus with the level of interoperation increasing (software eating the world as A16Z puts it) the execution of todays, for a given information system, can be for example the preparation of another project. Well, it's the nature of all working systems, tools, to serve a job and the job is serving another higher order job. The authors also point example of systems focusing in execution — when companies can, for example, optimize execution with real-time correction systems (p.6); I understood from this example that the execution step, as any other step presented here, is usually an identifiable sub-process that is self-contained — not broken in sub-steps. Out of this thinking would make sense for any system to be able to offer execution value by, for example, self-correcting itself under whatever offered execution steps.
Monitor — Of course, execution may have levels of performance, thus the step of monitoring, isolated or separated from execution, is an area to look at. It's usually the case when we need "an eye on the results" (p.6). Monitoring may account internal attributes, or measures generated by the solution/work being performed, but also the monitoring of the relevant external environment variables. Solutions can be greater when the execution is subject to performance issues, for example — you can simply assume that many things in our solutions world are just subject to failures, thus value is deferred to this step (opportunity value).
Modify — This may relate to the activity of evaluating the prior cycles, mainly execution (I am assuming) with the support from monitoring; therefore creating opportunity for course corrections. The modification steps focuses in assessing what, how and when things need to be change for improvement of the job task.
Conclude — the end of a job task, cycle, is usually the beginning of another. It's usually all in a chain. Thus, at this stage, we look at the systems, methods and solutions that can ensure the quality of the executed matter — it's completeness. If the core was to create a presentation, perhaps the conclusion is allowing the user to save, at least.