Lessons in Prototyping

by Aditya Dev Sood

This is the fourth in a series of brief pieces written from the deep and dark of Startup Tunnel, a new incubator based in New Delhi. You might also want to read dispatches one, two, and three.

We’re fully in the fog of it now. It’s not only the startups that are stumbling and searching and feeling their way forward. The tunnel metaphor would seem to apply to me and the rest of my team as well. Where once we felt clarity and purpose, we’re now lost in detail. Every startup is different, at a different point along the path, and with such different needs. We’re scrambling to serve them all in ways that do them justice.

The initial shock of arrival and feedback taking is over for startup teams. They now have real work to do in building out their product or in making it better. This is a multivariate problem solving process that can overwhelm founders if they don’t have the tools to organize and isolate the challenges they face. It’s with a view to supporting and enhancing their ability to conceptualize, articulate and prototype their product that we led them through two exercises: First a ‘product tour’ and then a ‘customer journey map.’

For the first, we asked founders for dirty prototypes of their products in the form of screens, howsoever crudely drawn or depicted. For the second, we asked our startups to draw a diagram of how a typical customer might go through the process of interacting with their product.

With startups at various diverse levels of product articulation, their ‘product tour’ varied tremendously in quality and refinement, stretching from the most basic ballpoint pen drawings on ruled notebook paper to a walkthrough of an actually existing and functioning website. In some few cases, we saw that our understanding of their proposition deepened and complexified because of the tension or disconnect between founders’ original words and what we now saw in these screen sequences. Anurag, for instance, showed the hand-drawn UI design shown to the right. He often spoke of his team's product in the idiom of a messaging app like Whatsapp. As we collectively reviewed and debated his interface design in relation to his business proposition, it became clear that there was a tension there that remained to be resolved. In several other cases, founders were struggling to to articulate the product form in a complete manner, being confused or conflicted about how it would or should best be expressed. For such teams, the exercise of bringing the product to dirty visual articulation was invaluable, for the startup to be able see where they really stood and what problems they really had, and also for us in the mentor group to be able to evaluate and understand what problems they were grappling with — to have things to point at, basically, as we talked with them.

To create their ‘customer journey maps,’ teams were asked to describe how a customer might discover the product, whether that was accidental or engineered, how they might arrive into the product, what further interactions on the app or website they might enjoy, and what their eventual end state might be, of satisfaction and exit, or of on-going engagement and interaction. We then also asked the group to tag the diagram for instances where there was a lack of clarity or more information required from users, partners or others in the value chain. The practice of making diagrams proved a really powerful way for founder teams to articulate complex and otherwise inchoate challenges at multiple points along the interaction path of a user. While there can be so much deceit and self-deceit in language, drawing leaves you no place to hide. Your diagram is either compelling and coherent or it isn’t and that becomes so quickly obvious when you put up eight or nine sheets against one another up on the board.

These exercises have clustered the cohort into three groups: First there are founders who have a pretty clear idea of what should happen once users began interacting with their platform. Second, there are founders whose diagram stopped short, the blank white of the page begging for more research, insight and thinking about what the product is really about. In a third case, founders want to do too much: arrows lead all around the page, in increasingly complex arcs, running at cross purposes with each other, fighting for space and attention.

Now that founder teams have made some kind of diagram of what’s inside their heads, they’re also at crossroads for what to do next. Where there are no complexities and contradictions they can move forward to actual build. Where there is white space they must go back to the field and clarify what they really want to do. Where there is too much on the sheet they must cut, prioritize, and clarify. We’ll be sorting the cohort into this subgroups in the coming week and meeting with them separately, so we can be more productive with each of them.

At the same time, I perceive that we’re struggling to get the right amount of contact time with our startups. One of big bets with this incubation program was that a structured introduction to user-centered product development along with startup operations would really help our startups, and this is an approach that I don’t see has really be taken in many other similar programs. We had planned, therefore, a Thursday evening seminar, a Saturday afternoon agenda of mentoring and group events, and a workshop allday Sunday. But attendance has been erratic at many these sessions. The only time I’m certain to meet all our startups is on Saturday afternoon. I’ve been struggling to understand exactly why we’re facing this mismatch. Is it that the design and delivery of the seminars and workshops has been choppy? Is it that startups are simply not attuned to predesigned, ‘canned’ forms of content as might be delivered through a workshop? Or i simply that this is too much of a time commitment, and we need to dial back our expectations of startups?

Preliminary feedback suggests a bit of all of the above. We’d introduced techniques of user research and context analysis at a point where startups had yet to feel the need for those techniques. Not all startups need all techniques. There is a mismatch between the didactic logic of the structured component of the program and the just-in-time imperatives of startup life. We are probably going to have to loosen up the logic of these seminars and workshops so that startups can control the conversation and get inputs on the challenges they’re actually facing when they want it and how they want it. We’ll likely have to rethink how the themes and topics are sequenced by week as well as how time is spent within each session. We also have too much contact time: some founders are in stealth mode and they have day jobs, others are already hustling and need all the time they can get on the street and in people’s offices. We’ll likely drop to two concerted meetings a week going forward.

You make something, you test it, You make something, you test it. This is the rhythm ultimately, that any process of product development must follow. The challenge is that very different kinds of skills are required for the two arcs of this process. On the one hand, technical, solutions-oriented, product-focused, on the other hand, social, empathetic, open-ended as to solution. And while in one case you have to be hard and apply your will to things, in the other you have to be soft and humble and attend carefully to the patterns and preferences of people. What is true for our startups is also true for our own practice. We have more listening and tuning ahead of us to ensure that we are doing right by our startups and we’re able to give them what they need when they need it.

This is the fourth in a series of brief pieces written from the dark and deep of Startup Tunnel (www.startuptunnel.com, @StTnL), a new incubator based in New Delhi. You might also want to read dispatches one, two, and three.