Dec 24, 2013

Why Kink?

the power of perversion

Fetishists, come out of the cave!
Like you, I'm fascinated by auto-erotic asphyxiationHallucinogenic frogs too; and base jumping. Who discovered these esoteric pursuits? Who first practised gavage? Who blazed the trail? Who charted the path to share their discovery with like-minded souls? How many people sacrificed themselves on the way? Who thought to make coffee from beans picked from civet feces? Most importantly: what other exciting destinations remain to be discovered?

That's the story behind the name of this blog, "How I got my kink". It was intended to be a series of fiction posts, telling the stories of how people had discovered their passion for aberrant behavior. Unfortunately, I still haven't found the time that empathetic contemplation of perverse behavior deserves. I was sidetracked on the road to aberration.

a treat for your mirror neurons
The blog has become a kind of a design / innovation blog, but there's still a connection with kink. For one thing, most good designers I know are deeply aberrant. How is obsessive attention to kerning or corner radius any less fetishistic when devoted to a web page than when devoted to, say, toes poking out of stilletos?

Innovation, done well, involves boldly poking where no (wo)man has poked before. It's straight-up aberrant behaviour. Innovators know the ridicule, and even shame. But persist! If our ancestors had shied away from aberrant behavior, there would be no golf!

Anyhow, that's the story of the blog's name. I hope, over time, to swing it back toward more popular forms of innovation, if the search filters allow it. In the meantime, I welcome your personal stories of redemptive perversion.

You are in a safe place.

Please share this post. If you comment, I'll reply. Thanks for reading!

My other blog is less careful.

Dec 17, 2013


App Lab at AVG Innovation is a Sprint Zero for greenfields projects. The video above is one of the deliverables of this sprint for the Patient Privacy Project.

This post describes the beginning of the process, the Inspiration.This post is part of a series describing the AVG Innovation App Lab checklist, using the Private Patient Records projects as a case study. The series starts here.

Privacy is one of the core topics of research at AVG Innovation, so when we were approached by PharmaPartners, Netherlands leading provider of patient record management systems, to collaborate on a project, we were interested. One of the top consumer privacy concerns is what might happen if employers or insurers had access to personal health information.

The table below provides an overview of the collaboration.

  • Global security software company 
  • “Be Yourself” brand
  • More then 150 million users in 170 countries
  • AVG Mobilation is #1 security app on Android

  • Netherlands' largest provider of information systems in the primary care hosting 9 million patients records. 
  • Current business is based on systems for Family Doctors and Pharmacists.
  • Pioneer in the area of personal health records. 
  • is the largest Personal Health Information System the Dutch market.
  • Build on mobile portfolio strength 
  • Develop new distribution channels
  • Bring privacy, protection, performance to new domains

  • Develop new consumer-facing business. 
  • Provide assurance of security and privacy to customers.
  • User Experience design
  • Security and Privacy solutions 

  • Data storage infrastructure 
  • Data access

starting criteria for an App Lab project

The criteria to take a project into an App Lab Sprint Zero are broad. This makes sense because:

  • viable ideas are often impossible to distinguish from non-viable ideas at first conception.
  • ideas coming out of Sprint Zero are rarely the same as the ideas going in.
  • the sprint is short, so unviable ideas consume minimal resources.

qualifications for a project champion

Projects should have potential to further the company's business goals, but the main criteria for a project to be taken into the AppLap process is a motivated champion. Qualities of a qualified project champion include:

  • personal belief in the opportunity
  • clear (starting) vision for the project
  • ability to promote the continuation of the project within the company.
  • at least 4 hours per week available to commit to the project over the six weeks of the sprint.

Within the sprint, the champion plays the role of Product Owner. For the Private Patient Records project, this was me. The project itself was led by Carolien Postma. Frank Laarakker led the team from PharmaPartners.

draft project scope

A few rounds of discussion with PharmaPartners led to the following:
In scope:
  • Domain: Self-care (including informal care)
  • Consumer segments:

    • People whose condition requires proper self-care; e.g., pregnant women, diabetics, heart patients, etc.
    • People who provide informal care; e.g., (first-time) parents.
  • Market: Netherlands. Value propositions can be validated in the Dutch market, but they are always created with a global audience in mind.
  • Business: B2C (consumer products/services)
  • Solution area: service
  • Go to market: 18 months to 3 years
Out of Scope:
  • Domain: Professional care, well-being (i.e., no immediate concern for health condition).
  • Market: BRIC markets
  • Business: B2B (products/services for health care professionals)

project brief

In a session with the project team and stakeholders from AVG and Pharmapartners, the brief was distilled to:
Create a solution to:
  • Connect consumers to Healthcare records.
  • Create the foundation for an ecosystem.

want more?

This description only scratches the surface of discussions, negotiations, and analysis that went into getting this project started. But the essential points are here.

I'd be pleased to respond to any questions or request for more detail in the comments below.

The next post will describe the second checkpoint of the Patient Privacy Project, User Research. The series starts here.

Thanks for reading!

Please share this post. If you comment, I'll reply. Thanks for reading!

If your interests extend to theory and philosophy, please check out my other blog.

Dec 10, 2013

Sprint Zero Checklist

App Lab

checklist, not steps
A previous post (here) compared best practice in Engineering, Marketing, and Design with the process of finding your way in a strange landscape by comparing the territory to a map, and then map to territory, orienting one to the other until they both make sense.

The next post (here) pointed out that, although they are navigate the same territory, the maps used by Engineers, Marketing, and Design, are qualitatively different; and that, although these different views of the world lead to misunderstandings, they were fundamentally complementary. The different views are summarised in this table:

Design Marketing Engineering
Value Opportunities Solutions
Desirability Viability Feasibility
Why How What

This post lays out an approach intended to orient Engineers, Marketers, and Designers to each other. The approach -- mashup of tools from Agile Engineering, Lean Startup, and Design Thinking -- is intended for use at the beginning of greenfield projects, i.e., projects without constraints imposed by prior work.

In Agile terms, the approach might be called "Sprint Zero". At AVG Innovation, we call it "App Lab".

Given enough iterations, a basic Agile process would no doubt cover the same ground; but the checklist is more efficient. It puts the first proper development cycle on solid ground.

solid ground

The App Lab approach was refined over the course of 9 greenfields projects to develop new products or service propositions (including Family Center and the Carefree Patient Record concept). It was developed to ensure multi-disciplinary teams start new projects with a clear and shared set of priorities. Basically, it's a checklist.

scanning the horizon

The App Lab checklist encourages a 360° view of the project, including User, Business, and Technical considerations. Working through the checklist leads team members from different disciplines to discuss what they already know about the problem, to develop a shared understanding, helping the rest of the project go faster. By the end of the checklist, the team has a set of working hypotheses on what it will take to make a product that is Desirable, Viable, and Feasible.

natural order

In principle, there is a natural order to the checklist, with items relating to Desirability first, then Viability, then Feasibility. Because Why we sell a product determines How we sell it, which determines What we sell. Customers drive Business drives Technology. So the natural order would be Design, then Marketing, then Engineering.

In practice however, it's not possible to address either Design, Marketing, or Engineering in isolation. An award-winning design that can't be built, an incredible technology patent no one needs, or a fast-selling product that loses money ...all failures. Successful Design, Marketing, and Engineering are inextricable from one another.

Innovation projects commonly start with a compelling inspiration from Design, Marketing, or Engineering; but usually 2 out of these 3 perspectives are only vaguely outlined. In these cases, you have to start with what you have, so we've found it's better to approach App Lab as a checklist rather than an ordered set of steps.

Use the App Lab checklist to surface what you already know, and to fill in any gaps. Be prepared to revisit items on the list as your understanding of the problem evolves.


How long does it take to go through the list? It's possible to go from inspiration to coherent, validated product/service proposition in 4 weeks, but we plan for six weeks because i) team members are working on other projects in parallel, and ii) the extra gestation time improves the quality of thinking. The process is time constrained, so deliverables must be tailored to fit time and resources available. This encourages a mindset of practicality over perfection.


The checklist validates that an idea has been considered from Design, Marketing, and Engineering angles, and confirms that the core proposition is coherent and acceptable to users. It validates that an idea is worthy of further investigation. The final deliverable is a pitch to budget holders for funds to proceed to the first iteration of development.


Below is an overview of the App Lab list. In the next posts, I'll walk through a case study, item-by-item, based on our experience with the Carefree Patient Record concept). The next post describes Inspiration.

Item Input Activities Output
Inspiration Champion (product owner) Draft statement of scope Project Brief
User Research Project Brief User visits,
Consumer review analysis
Experience Flow w/ pains & gains
Jobs-to-be-Done Pains & Gains Analysis (workshop) Jobs-to-be-done. (Social, Emotional, Functional
Competitive Landscape Jobs-to-be-done Desk Research Ranked feature list (Kano model)
Business Model Canvas Customer description
Competitor Landscape
    Desk Research (Workshop) Selected (provisional) Business Model Business Case
    Design SketchingBusiness Model Canvas
    Customer Description
    User Scenario sketching,
    Screen concept sketching
    Key User Stories Design
    Principles Screen Concept sketches
    System Concept Business Model Canvas
    User Stories Jobs-to-be-Done
    Design Principles
    System Design Review Minimum Viable Product , Use Cases System Concept Document
    Lo-Fi Prototype User Stories Design Principles Sketching (workshop) Lo-Fi Prototype (Wireframes)
    User Validation Prototype User Description Define Hypotheses, User Test Findings Presentation
    Pitch Business Requirements (Business Model Canvas & Business Case),
    User Requirements (Job-to-be-done & Design Principles),
    Technical Requirements (System Concept Document)
    Presentation creation Request for resources to continue development.

    Please share this post. If you comment, I'll reply. Thanks for reading!

    My other blog is full of esoteric rants.

    Dec 3, 2013

    Bat, Bloodhound, Pigeon

    roadkill on the path to innovation

    An earlier post (Map and Territory) pointed out the basic oneness of Agile Engineering, Lean Startup, and Design Thinking. Each compares territory to a map, and then map to territory, orienting one to the other until they both make sense. The Territory in this metaphor stands for concrete facts that either align with or obstruct a chosen path. The map stands for the models of reality we use to find our way.

    So if Agile Engineering, Lean Startup, and Design Thinking are all essentially the same, why are they three things?

    Let's complicate the Map and Territory story.

    Bat, Bloodhound, and Pigeon have sharpened their mapping skills over the years and are pretty happy with their different maps. Bat navigates by sonar, so his map is a kind of sonogram. Bat's map seems nonsense to Bloodhound, who gets around by smell; her map shows scent trails. Pigeon navigates by magnetoception -- he perceives direction, altitude and location through magnetic fields. So Pigeon's map is chart of magnetism. Pigeon doesn't see any use in sound or smell maps.

    But reality keeps intruding. Bat has frequent near-misses with suspended power lines. Bloodhound keeps running into rivers and snowbanks. And once or twice a year, electromagnetic disturbances caused by solar flares leave Pigeon completely lost.

    Sharing stories one evening at a forest meetup, Bat, Bloodhound and Pigeon come up with an idea: why not put their maps together? So they overlay Bat's map on Bloodhound's map on Pigeon's map. They set out on a venture together and works! With the combined-perspective map, the world seems a friendlier place.

    Bat is an Engineer, Bloodhound is a Marketeer, and Pigeon is a Designer.

    So if Agile Engineering, Lean Startup, and Design Thinking are all essentially the same, why are they three things? Because they represent three different perspectives on the same reality.

    Agile Engineering Lean Startup Design Thinking
    ...thinks innovation springs from... Technology Customer Development Insight into User Motivation
    thinks Agile Engineering (is)... best practice should do only what is asked by customers. hasty and naïve
    … thinks Lean Startup (is)… kills great ideas prematurely best practice superficial and short-term
    … thinks Design Thinking (is)… slow and naïve should be outsourced to customers best practice

    These (comment baiting) caricatures highlight the different discipline-centric perspectives of Agile Engineering, Lean Startup, and Design Thinking to what is fundamentally the same reality. I've come across them all in the wild.

    At ground, the different approaches are properly complementary. They address the What, How, and Why of successful innovation.

    Agile Engineering Lean Startup Design Thinking
    What How Why
    Solutions Opportunity Value
    Feasibility Viability Desirability

    I call for a new mashed-up approach, combining the tools of Agile Engineering, Lean Startup, and Design Thinking. Who will join me?

    Next week, I'll try to make a more concrete proposal.

    Thanks to Nicolien Adema, Jeroen Frumau, Lorna Goulden,  Laurens Massee, Han Toebast, and Jay Vidyarthi for constructive contribution to this post.

    Thanks to Michael Held, whose project on 2nd order observation maps inspired the overlaid perspective metaphor.

    All exaggerations and misunderstandings are entirely my own.

    Please share this post. If you comment, I'll reply. Thanks for reading!

     My other blog is full of personal rants.