#4 | Customer Obsessed
You already know that by night, I moonlight as a superhero and newsletter author, but my day job is software engineering at Amazon Alexa. Amazon is one of the most famous American success stories and I’ve tried to observe what drives that success. One of the most notable features of Amazon’s culture is the strong focus on measurable end customer value- we use the term “customer obsession”. When you read entrepreneurship advice from sources like Y Combinator (the most famous tech startup accelerator), they always harp on the need to stay customer-focused. So many startups fail spectacularly because they build something impressive that turns out to have no paying customers—YC calls this “Solution in Search of a Problem”. In fact, the way they think about startups is completely different. To them, a startup is a hypothesis: an attempt to find and exploit some unconquered pocket of customer value. The founder should be to test their hypothesis as efficiently as possible, by executing quickly and then iterating based on customer needs.
I don’t think this customer-focused way of thinking comes naturally for a lot of sciencey-, or artsy-types. How many times have you heard an artist complain about the tug-of-war between making money and staying true to her artistic vision? I’m reminded of my play habits in middle school. I had a big Lego robot set and found building projects from the instruction manual boring, so I would try to build my own vague, ill-defined but ambitious projects. Very often the design would be too hard or impractical and I would scrap it halfway through. I wonder if this might actually have hidden upsides (like maybe improving spatial reasoning) but the downsides were that I rarely made “finished concepts” which I could use or show off to anyone.
This week’s project—the follow-up to last week’s—challenged my discipline to stick to the MVP plan. Early on I had a working prototype which contained all the essential functionality and navigational elements, but it was ugly (black text buttons on black background). Since I plan to actually trial the app for my own personal meditation, I decided that I should add styling to make it look a little better. For the projects so far I’ve been both the builder AND the customer, which is surprisingly tough. It’s a lot harder to be the customer when you’re also building the product—you start to overthink your own intuitions and wonder how much of your judgment is biased by your close involvement to the project, instead of representing a typical user. For example, how much or how little functionality should you add before calling the project “done”? I think this will come with practice.
Project #3b: Guide My Meditation (Part 2)
You might want to go back and skim last week’s post where I described the idea of this guided meditation app (concept wireframe copied below).
In a nutshell: it presents a flowchart of topics and subtopics that help you choose the meditation track you want. Here are some notes about the implementation.
Navigation
Internally I represented meditation (sub)topics in a tree node data structure called MeditationTopic, each with multiple children that could contain more granular subtopics (or links to several YouTube videos, in the case of leaves). The app only has a single page/activity and on each button press, the layout gets cleared and redrawn with either the children of the clicked node or the parent’s children (if you navigated back).
OnClickListener and Tags
One useful tidbit: Click events in Android are handled by a standard onClick function with a fixed signature
onClick(v: View) { … }
Note that this function only takes a View, which is the UI element that was clicked, as input. This can be annoying—ideally we’d like to pass more data in. For example, if a button corresponding to the Relax MeditationTopic was clicked, we’d like onClick to get a reference to the Relax object itself (for instance, to get its children and render buttons for them).
To address this, View objects have a field called tag
which can hold any arbitrary object. We simply point each Button’s tag
to the corresponding MeditationTopic instance. This is how the view layer can hold references to the underlying model layer.