Timo is a startup-minded lean startup and marketing / growth hacking enthusiast, a Chief Marketing Officer at Plan Brothers, and a part-time growth marketing consultant and trainer at Efekta. He's also a Rovio, Startup Sauna and Aalto Uni alumnus.
Executive intervention in product development – an opportunity or a threat?
Have you ever witnessed a situation where a very senior executive, removed from day-to-day product development, hears from someone they are talking to (a customer, a friend, etc.) that there is a problem with the company's product, and approaches the product team with a question: "Why is this not fixed? This needs to be fixed right now!"?
If you've worked in a company with more than maybe two or more levels of hierarchy, it's very likely.
I haven’t heard this scenario discussed often, perhaps because it's outside of the usual product development / management process. And that's where this realization stems from:
There usually is a reason for why the issue hasn't been fixed prior to senior management intervention.
Either it hasn't been caught (in digital products, perhaps the customer using the product has a weird combination of device and operating system or some other edge case like that), or it's been de-prioritized by the product team (maybe exactly because it's an edge case and doesn't touch a big portion of the customer base or potential market or some rational reason like that).
The point: whatever the reason, the executive would be wise to understand that if she just gives an order to fix the matter and then goes on with her usual work, she risks missing an important opportunity.
The opportunity
Why? Because the product development process has resulted in the current state of affairs. Someone has made the decision to spend the team’s time on something they see even more important. Fixing the issue might be very problematic for technical reasons the executive most likely doesn’t have time nor patience to learn about. Or it might impact such a small percentage of the user base, that even if it were relatively easy to fix, it would still have negative return-on-investment (ROI).
“And what is the opportunity?”, you ask. The team can work with the executive to help her understand why the current process has lead to the situation, and ask for advice on how to fine-tune the parameters of the process (such as decision-rules of prioritization decisions) or re-engineer the entire process.
The most likely outcomes from the discussion
For example, if there is a severe issue the team didn’t know about, they might ask for help in developing the company’s capability in catching these kinds of issues, perhaps by using a partner company to conduct acceptance testing / quality assurance on a broad device matrix (the company has bought a ton of different devices and has the capability to test your app out with these different devices).
Or, it might be that the executive realizes that she hasn’t communicated a detail of the business strategy that affects on the team’s prioritization decisions, and thus by making these details more explicit, the team undertands they need to update their prioritization rules.
Most likely, though, the executive realizes the team has been doing their job just as they are supposed to, and she just didn’t realize at the outset that although very frustrating to this one customer, it’s an edge case, and as such, won’t be profitable to address with a technical solution.
Rather, the executive can come up with ways on how to fix the situation with the customer that does not require changes in the product. Such as suggesting them to update their operating system or in the case of a high-value customer, even consider sending them a device on which the product works as intended by the product team.
In summary: an opportunity for alignment
So at the end of the day, if the executive chooses to avoid her knee-jerk reaction of just telling the team what to do, and instead asks why the current process hasn’t lead to fixing the situation as a matter of day-to-day operation, there is an opportunity to really help align the product team and the business strategy in a very concrete and specific way.
A No Stack Workweek Playbook – Examples of API-Driven Business Opportunities
How would you, in practice, combine multiple APIs and a ”last mile” user experience to deliver added value while minimizing need for tech-heavy development work? That is the question I’m going to be exploring in this blog post.
In my previous post, I combined several concepts into what I call the ”No Stack Workweek.” The name comes from an earlier concept called the ”No Stack Startup,” but I wanted to make a distinction between a startup (which is typically growth-oriented and often VC-funded) and a cash-cow business that enables a ”4 Hour Workweek” (a concept developed by Tim Ferriss in his book of the same name). Check out that previous post if you’re interested in how I came up with my combination of these concepts.
Building a business is kind of like juggling and driving a unicycle at the same time – an interplay of multiple stakeholders and the machinery of processes (which are sometimes invisible) that enables the simultaneous delivery and capture of value.
Building this machinery is usually expensive and time consuming. An entire movement called “lean startup” is trying to explore how to minimize up-front building. The goal is to ensure that if a business doesn’t take off as envisioned, the waste of resources is minimal. However, lean-startup thinking usually isn’t focused on the lower-level engineering-related steps one could take to minimize the build process. Rather, it's focused on avoiding building at all. It utilizes techniques such as using landing pages to test interest (smoke testing) or delivering value manually (concierge MVP) before building anything.
Additionally, discovering lucrative business opportunities and executing them is hard. It is not easy to deliver and capture value in real markets of real people, especially in a niche that's accessible to a new player within a given window in time. If it were easy, everyone would be an entrepreneur working for themselves.
The “No Stack Way” reduces the need to invest in basic infrastructure
What I like in the “No Stack Startup” approach is that you pay other companies to maintain APIs that create value for both you and your end-customer. That way, you don’t have to care about stuff other companies can do for you, stuff that is getting quickly commoditized, anyway. The easy examples include Amazon AWS or Heroku for handling server infrastructure, Twilio for SMS and voice infrastructure, Stripe for credit card processing online, or Square at the point-of-sale.
Even before anyone used the term “startup,” banks had always been securing financial transactions for new businesses, accountants and lawyers had been handling the paperwork, and so on. The difference today is that you can use programmatic interfaces (APIs) to automate all of those tasks so that no humans need to be involved in repetitive “infrastructuresque” chores. These tasks are necessary, yet they are commodities. That is, they are hygiene parts of the value creation/capture process that produce little or no competitive edge.
So how could we build an entire business almost entirely using other companies’ APIs to assemble a value-creation-and-capture machine that requires a minimal amount of coding effort?
How would you deliver a package via APIs?
Beyond using the obvious APIs from companies like Amazon AWS, Twilio and Stripe, at first I draw a blank when it comes to whole end-to-end architectures.
Let’s say we’d want to automate end-to-end delivery of postal packages. I'm not saying that would be a great business opportunity at this point, but let's assess whether or not we could do it the "no stack way." Do we have a company that offers an API without minimum volume limitations or a requirement for long-term contracts to ship packages? Does that API include tracking of packages to make the user experience smooth? How would I know?
When I search for “package delivery API,” the first results include a company called EasyPost, which seems to be exactly what I’m looking for. The search also returns multiple articles from Programmable Web (PW), which is a site specializing in listing APIs, and 92 of them are related to shipping. However, PW’s listings are very qualitative, and comparing the APIs seems to be somewhat “apples and oranges.” It would require quite some investigation effort to determine which of the 92 APIs actually are suitable for our hypothetical business. The same goes for EasyPost. How do I know if it is actually a good service for this use case?
A playbook for “no stack” businesses?
What if there were a playbook of tested-out “plays” of different stacks working together? More than just a list of APIs, such a playbook would also include some thoughts on how the APIs fit together, how pleasurable they are to use, and how their pricing works for very small businesses. PW could be a great source of discovery of new APIs, but the value of a playbook would be in more than just the technical aspects of an API and a technical proof of concept. As they say, the devil is in the details, and only by testing a service (not just the API) in the context of an actual business process can you learn enough about its properties.
This would obviously require lifting the kimono, as they say, regarding the business and technical architecture of a company, which is something entrepreneurs often aren’t willing to do. Often when we read about the “stacks” of companies such as Uber (https://eng.uber.com/tech-stack-part-one/), for example, the descriptions are so high-level that they don’t easily allow us to understand exactly how the different pieces have been glued together and how well they actually work.
Hardware DIY sites already provide playbooks for DIY enthusiasts
An analogue here, much more fitting than PW, could be hardware DIY project sites such as Hackster.io (https://www.hackster.io/arduino/projects) or DIYhacking.com (http://diyhacking.com/diy-projects/arduino-projects/).
Both of these DIY sites have a familiar format for project descriptions that start with an interesting use case (an analog for our concept would be a business case). The sites then go on to show what parts are needed (a list of APIs in our case) and demonstrate how the project was completed. Most importantly, the sites discuss how the different parts were combined, including what needs to be taken into account for the components to work well together. Such a discussion might also include the different alternatives that were tried in the process, and why the choice was made to use a specific component instead of another in the same category. This sort of discussion is what’s missing from PW.
Making it as easy as drag-and-drop
The playbook could even use a visualization technique similar to popular drag-and-drop programming environments such as MIT’s Scratch (https://scratch.mit.edu/), Google’s Blockly (https://developers.google.com/blockly/) or Berkeley Snap! (http://snap.berkeley.edu/). By creating connector nodes similar to the way that Zapier (https://zapier.com/) works, an integration of two APIs would need to be created only once, and afterwards people using those APIs together could avoid programming entirely.
This combination of a business case and a technical end-to-end implementation guide (or even prefabricated sample projects) would make assessing the suitability of APIs much easier, since instead of reading through the sales materials of the API provider, one could directly get a first-hand account of how the API actually worked in a real-life scenario.
Playbooks for reducing business “boilerplate” and increasing innovation
This way, when building a new business, one could more easily discover new APIs suitable for the situation, as well as get help in the actual implementation. Most of the startup's work could then go into the unique aspects of the business, instead of the setup of what is known in programming as “boilerplate."
When reading other peoples’ showcases, it’s much easier to be “creative” when you have stencils that you can combine, instead of facing a blank slate. Since transferring a business model that's working in one geographic market to another market is already the business of many companies, there isn’t really anything dramatic in this kind of copying and pasting, except that the actual implementation would be much cheaper. Many business ideas that would otherwise be left in the heads of up-and-coming entrepreneurs due to lack of build resources might now get built and delivered to market, and that would benefit the end-customer.
Do you have a budding idea for a combination of APIs that could form an end-to-end business already? Do you feel like sharing it?
Let me know on Twitter, @therttua – and let’s talk more!
The No-Stack Workweek: The Art of the Possible meets the No Stack Startup meets the 4-Hour Workweek
What if there were an easier approach to becoming a successful technology entrepreneur than what the venture capital financed model of building tech unicorns such as Uber and AirBnB has to offer? Could the “No-Stack Workweek” or a combination of “No Stack Startups” and Tim Ferriss’ “4 Hour Workweek” be the answer?
“..perhaps I should start working on a startup instead..”
** UPDATE: Based on initial feedback to this post, I’d like to clarify that when I’m talking about tech entrepreneurship and the “no stack startup” approach, I specifically am not talking about creating the next Google or Microsoft (heavy lifting kind of tech) but instead gluing together existing pieces of services via API’s and focusing on the last-mile UX (this is my understanding of what the “no stack startup” means). So think Amazon or Zappos (in their early days, with their little-to-no inventory approach to e-Commerce, by leveraging partners in fulfillment) type of tech-enabled service business rather than the Curious AI company or Google type of tech business. **
A relative of mine told me when having a conversation about work: ”I’m working so hard and getting paid only marginally more than when I was doing less demanding work – perhaps I should start working on a startup instead..”
As a person with some startup experience, I responded with my view on the expected value (average of different payoffs in different scenarios weighed by their relative probability) of a startup: most likely lower than that of a 9-to-5 job, due to the high failure rate, convention of paying lower-than-market rate salaries even when VC funded as well as long hours anyway.
But then we spoke about another relative who is making a decent living by buying a few used expensive items abroad per month, and importing them for a profit. Since this relative already has a committed buyer (the demand) before buying anything, the income is relatively secure.
“Startups try to search for a profitable but scalable business model while being unprofitable for a long time”
We agreed with the first relative that if the latter relative would attempt to scale this operation (with the help of, say, VC funding), most likely the profitability would quickly decline as the ”good deals” on the market are quite rare, and profiting only possible when finding rare gems (or pricing errors) on the market.
So here we have a profitable but not scalable business model. Startups try to search for a profitable but scalable business model while being unprofitable for a long time – in the hopes of becoming profitable with scale, helped by e.g. digital technology and/or leveraging crowds (such as AirBnB and Uber). For every Uber and AirBnB there are a hundred other very similar companies that we never hear of, but still burn through thousands, or millions of euros or dollars of their investors’ money.
the ”good deals” on the market are quite rare
So I suggested to my relative that he check out Timothy Ferriss’ book ”The 4 Hour Workweek” (sometimes shortened to 4HWW) to think about a business that requires very little risk or maintenance but would give some extra ”passive income”. However, my personal experience about the 4HWW model is that in practice finding a business that is both profitable and low-maintenance is much harder than how I feel Ferriss makes it sound. So I let the whole thing slide – until..
Today everything seemed to click. I’ve recently read many very interesting blog posts about aspects that today just came together when talking to a friend who is an experienced data scientist and enterprise consultant. He gave a talk about how ”software is eating the world” (a phrase attributed to tech entrepreneur and investor Marc Andreessen) and how one can build tech solutions with cloud software 10x faster than just 3-4 years ago thanks to both advances in open source software as well as cloud providers’ commercial efforts (Google Cloud, Amazon AWS, Microsoft Azure, etc.) to make using these software packages as easy as possible without configuration.
one central capability for a ”smart creative” is the ”art of the possible”
My data scientist friend also referred to Eric Schmidt’s ”How Google Works” presentation and ”smart creatives” working in a near-chaotic way on wicked problems with a large degree of freedom, as up-front planning doesn’t help in these scenarios. My friend added that one central capability for a ”smart creative” is the ”art of the possible” (as an actual concept it seems to refer to political pragmatism, but that’s a coincidence here), with which my friend meant that you need to have a rough understanding of what is possible in order to be able to come up with groundbreaking innovations leveraging existing technology in new ways as well as building small pieces of new technology to make these new combinations possible.
An example (I’m making this up since we didn’t discuss this in detail) would be using the accelerometer of a smartphone to do sleep tracking, and thus building on a technology platform provided by Apple and Google, instead of having to build expensive dedicated hardware, as well as leveraging the App Store and Google Play Stores for distribution. In this way a small team can make a decent amount of money with quite a niche product without needing much upfront investment. Still, for someone to be able to come up with such a business requires mastery of the ”art of the possible” in the domain of mobile technology and sleep monitoring science.
“..it feels like it is an amazing time to be a creative entrepreneur utilizing emerging no stack techniques..”
So how could one take this notion forward? Earlier, I bumped into a Slideshare presentation by VC Albert Wenger quoting Andy Weissman’s blog post called ”No Stack Startups” (http://blog.aweissman.com/2015/05/no-stack-startups.html) where Weissman concludes with, among other things that ”it feels like it is an amazing time to be a creative entrepreneur utilizing emerging no stack techniques…”. By ”no stack startups” Weissman means ”instead of being good at many things, companies can just focus on the last mile of value they provide, the one thing they can excel at better than anyone else. Maybe this should be called the No Stack Startup - services that can focus on doing only one thing - hopefully well - and utilize other services for everything else.”
Yesterday I read Jon Lax’s Medium post ”Great Products Don’t Happen By Accident – Using playbooks for designing and building products” (https://medium.com/great-products-dont-happen-by-accident/great-products-dont-happen-by-accident-f46323d8ad94).
“let’s run Statue of Liberty Buck Sweep”
Lax suggests building a ”playbook”, or documenting ”plays” similar to how NFL coaches do so that they have a set of adaptable responses to a set of reoccurring circumstances, which have been rehearsed with the whole team so that the team has common language for a very specific maneuver so that when the coach says “let’s run Statue of Liberty Buck Sweep”, everyone knows immediately what to do.
After all, a lot of time in startups and big companies alike is both wasted on re-inventing the wheel as well as following preset processes that don’t match the current situation. Why wouldn’t startups or corporate product development departments document a set of ”plays” which would create unambiguous shared language as well as be reused while retaining flexibility in a changing landscape that still share some commonalities? Kind of like ”process 2.0 for product development”.
The blog posts that have been marinating in the back of my head combined with what my friend said today, sparked the question that could we do ”No Stack Startups” (meaning providing only the last mile user experience with low technological risk by using other people’s platforms and products via API’s) in a systematic way (hence, the ”playbook” thinking) while not requiring unicorn scale and VC investment?
“..so cheap that it wouldn’t have to have any kind of scale to provide a very nice living for its solo founder or small founding team..”
Let’s say instead of trying to have everyone and their uncle become startup entrepreneurs, could technology entrepreneurship (if we remove the requirement of scaling the business) be something that is done as a side job?
A ”no stack startup” could, at least theoretically, built for so cheap that it wouldn’t have to have any kind of scale to provide a very nice living for its solo founder or small founding team. In this way it would end up being very similar to what Ferriss is proposing in ”the 4 Hour Workweek”.
In that way, a person could slowly and with low risk, build entrepreneurial capability that could then be either used in intrapreneurial activities inside of big corporations (not all people, after all, hate working for big companies), for serving lifestyle entrepreneurial aspirations (say, serving a market which traditionally isn’t seen at all attractive by tech entrepreneurs), or to eventually go on to be a founder of a tech startup unicorn, depending on the person’s risk aversion profile.
If the answer is ”yes” or ”maybe”, the next question is: what would be required for this kind of approach to work? That is where I believe ”the art of the possible” (as defined by my friend) comes in. One needs to know what relevant existing technologies there are, how to leverage them in the given domain, as well as some basic marketing/finance capabilities so as to get the product to market in a way that the market can accept (UX, pricing, support, etc.) without overspending so as to require massive injections of investment capital and thus bring in demands of five to twenty X exit multiples the venture capital investors require.
And again, to keep the costs down, this would need to be done by a very small team or a ”one (wo)man band” of ”smart creatives”, which places certain requirements on who these people can be. Since typically the people with the ”art of the possible” covered are rarely design, marketing and finance experts at once, the next question seems to be: are there some aspects to the process that are often time similar that they could be distilled into ”plays” to form a ”playbook”?
After reading the blog post about product development ”playbooks”, I think yes. And I think the same goes for many go-to-market activities. Especially if there is a community of these ”no stack startup” entrepreneurs working together. I think even prototypes or blueprints of different business model ”plays” could be distilled, which is something Alexander Osterwalder has tried to do by coming up with the Business Model Canvas to compare different established businesses’ business models, and Ash Maurya taking this closer to the problem areas of startups with the Lean Canvas.
Where could we get the first brave ”smart creatives” wielding the ”art of the possible” while simultaneously supporting them financially to have time to learn from initial mistakes, as well as distilling the learnings into a ”playbook” so that people coming after the pioneers could ”stand on the shoulders of giants” instead of starting from scratch every time?
After all, if cloud technology (Amazon AWS et al) has made it possible to cut down on software development costs up to 10X or even more, we might be possible to come up with social technology to cut down on the ”trial and error costs” in a similar way to make searching for these niche businesses much cheaper and thus attractive to rookie entrepreneurs with no previous successes under their belts giving them creditability and providing them either money in the bank and/or access to investor financing.
If the challenge is to encourage low risk, moderate reward part-time tech entrepreneurship, what would your playbook look like?
Look forward to hearing from you, e.g. on Twitter – tweet me @therttua !
The Second Wave of Lean Startup Books: Scaling Lean and The Leader’s Guide
The fathers of Lean Startup, Eric Ries (The Lean Startup, the Build Measure Learn loop) and Ash Maurya (Running Lean; the Lean Canvas tool) have been at it again.
While Ries writes about how a large organization can establish a culture of leveraging lean startup principles, Maurya has gone on to focus on scaling the core process itself, introducing an interesting concept of the Customer Factory Blueprint, borrowing ideas from the Theory of Constraints.
Both topics (Lean Enterprise and Lean Startup Metrics / Lean Analytics) have been written about before, but it’s always interesting to hear from the pioneers themselves.
"Are they worth my time?”, you might be asking. Depends on what you’re looking for and what you’ve read before. There’s a lot of books (most likely even better than ‘The Leader’s Guide’) regarding using Lean Startup in a large organization, so Ries’ book will most likely be useful only if you’re very interested in the topic – say, if you’d be building an internal accelerator or working actively with developing corporate culture.
Knowing how to focus laser sharp is a core requirement for a startup with scarce resources. Ash Maurya seems to have something very interesting here regarding that topic. So if you’re building a scalable growth business (i.e. not consulting), “Scaling Lean” might give you much needed help in focusing your efforts. Also, be sure to read “Lean Analytics” (4.08 / 5.00 stars on Goodreads)
Since I haven’t read either of the books yet, as the mailman just brought them, here’s some other people on how they like the books:
Huffpost on “The Leader’s Guide”
Goodreads reviews on “The Leader’s Guide” (3.60 / 5.00 stars)
Kevin DeWalt reviews “Scaling Lean”
Goodreads reviews on “Scaling Lean” (4.73 / 5.00 stars)
This post is about the definition of done in software development. If you do not know what that is, you might not get much out of this post either.
While at the Lean UX NYC 2015 conference last week, we had an interesting open space discussion on the topic – worded in a manner that can be described as “highly leading” – of “why people hate agile”*.
Well, without going too deep into that discussion itself, the major insight was that people seem to confuse agile principles (the 2001 Agile Manifesto) with specific agile process incarnations, such as Scrum. And the reasons the people in that discussion group cited as to why they hate Scrum, was the prescriptive nature of it, and often, the many (often poorly understood) meetings it describes.
Training wheels
However, we also concluded that Scrum is a useful starting point for a team starting on a new project, and can be seen as training wheels on a bicycle – and that dropping Scrum requires a very mature and disciplined team that automatically does the things Scrum holds your hand through. Anyway, I digress.
Another major insight of that open space discussion was that people have different understandings of what the definition of “done” is. Meaning, product, ops and sales all mean very different things when they ask if a new product feature is “done”.
So is it done, or done-done?
This results in interesting discussions like “so is the feature done, or done-done?”
My major epiphany from this was that since 1) “done” is such an overloaded word with so many ..definitions and 2) people farther away from the day-to-day of software development have little patience for the minutiae of software development specific processes or semantics – and since the whole point of the definition of done is to drill into the semantics of that word – perhaps we should avoid the use of the word “done” completely.
Pig-latin, the other kind of high-level language
Instead, how about we invent a team/project specific word altogether which is totally pig-latin, and thus by definition, totally free of existing meaning and thus risk of overloading?
I might be pushing it here, but what if the word itself in fact was literally the definition of done? Meaning, that the word used instead of “done” would be an acronym / mnemonic of the checklist of major items that are in the definition of done?
So as an example, if our team’s definition of done is “in order for a feature to be done, all bugs need to be resolved, end to end testing passed, deployed to production, handover to ops complete”, the status previously known as “done” would from now on be called BEDH. Thus, when the product owner next time wants to know, if something is done, she can now ask: “so is this feature now BEDH?”
Watering it down for the layman
Ok, ok. I might be going overboard with this for the majority of us. So how about, for the majority of us, we’d stop using “done” as a status for our work items / features, and instead use a more distinct status like “deployed to production”, “feature complete”, or similar?
No more “is it done, or done-done?”
Finally, if you think the idea of inventing acronyms is ridiculous, then how about these guys: https://youtu.be/-aeNmupIYQk?t=41s ? Also, these guys do it as well: http://workingwithmckinsey.blogspot.fi/2014/02/MECE-at-McKinsey.html
*although I participated in the discussion, I by no means personally “hate agile”, or even Scrum, even if Scrum is definitely not perfect either.
Here’s my thoughts on Wednesday 15th talks in Lean UX NYC 2015. http://brooklyn.leanuxnyc.co/schedule/
What is Lean?
Opening up the event, John Shook spoke about the history of Lean. His core thesis was that Lean is about learning and is situational, and thus lean transformation cannot be done in a step-by-step guide manner. Instead, it should be built like house with value-driven purpose (meaning, what problem do you solve for your customers), supporting processes and capabilities, and the culture of the organization should be taken from where it is to where seen that it should be at.
Adapting Lean Startup to bigger companies
Brant Cooper spoke about the 5 necessary changes for Lean Startup in Enterprise. Althought I don’t remember all of the five, the core point was that, along the lines of Clayton Christensen (Innovator’s Dilemma), big companies excel at sustaining, incremental innovation, and they have built mechanisms and processes to support that, which are by their nature sometimes hindering the way lean startups operate. The key points included ditching the sole focus on shareholder value, and short term profits.
A tool Cooper mentioned briefly was the Experiment Map.
Funneling customer feedback back to product development
Lauren Gilchrist from Pivotal Labs spoke about “getting back in the building”, i.e. how to transform customer feedback into product work, and her key takeaways included “affinity mapping” sticky notes to groups and then naming the groups by problem. Then, the groups should be put on a two-by-two matrix with the axes of “product killer” potential and uregency. I.e., her point was that things that can end up killing your product urgently should be dealt with first.
Tami Reiss spoke about why everyone should be a scientist. What she meant by that was first that a scientist is a person who uses the scientific method, design hypotheses and go on to (in)validate them, and also shares their results – also failures! – with the wider community so that everyone has the results at their disposal and people don’t have to do the same mistakes again.
The Emotional side of Lean UX
After the lunch, Oonie Chase spoke about not getting stuck in always requiring evidence, but also leaving room for trusting your gut. The most concrete takeaway was that breakthrough innovations (Sydney opera house, as her example) happen often on the borders of what’s possible, and if you only focus on what’s “probable”, you miss out on those awesome products that jump curves.
So her practical tip was to do “100 post-its” where you come up with 100 different solutions to a problem in a team lifting the constraint of technology, and the point is to exhaust obvious ideas in order to get into the twilight zone of possible and impossible, and perhaps get some actually novel approaches that after all can be done.
Bringing another viewpoint to the topic Bill Beard spoke about branding and the product itself making an emotional connection being the only real competitive edge as traditional advertising is beyond the reach of many.
The Build Trap and validating assumptions
Melissa Perri spoke about the build trap, meaning a place where product/market fit has been found, and you keep on adding features. Her takeaway was roughly that when adding features, assumptions of why things should be done, need to be tested rigorously and bad ideas killed as early as possible.
Vetting the assumptions included questions such as
Along the same lines, Steven Cohn of Validatedly spoke about validating customer demand, and his point was to validate assumptions about problem and solution space by forcing trade-off decisions in the heads of customers by asking people who are interested in a product to give out their time (prolonged test sessions), money (pre-orders like Kickstarter), or referrals (social media etc.).
Practical tools for day-to-day product development
Aaron Sanders and Natalie Hollier both spoke about the tools of product development, such as affinity mapping, dual track scrum and so on. Opportunity Assessment was mentioned.
Hollier brought in very interesting concepts of Opportunity Backlog, MVP Design Workshop, Research Sprints, User Story Mapping and Goal Driven Business and Funding Outcomes (not Output). Her blog here: http://www.nataliehollier.com/
Lean Product Management – talk at ProductCamp Helsinki 2014
Lean Product Management for me is about 1) understanding what is important in product management, 2) what is important in lean and 3) how the tools from lean and lean startup could be used in the context of product management.
Read below a summary of the points in my talk at ProductCamp Helsinki 2014 organized at the Aalto Design Factory, Saturday April 5th 2014 that was aimed at the nascent community of Finnish product managers.
#pcamphki @therttua keynotes about his lean #prodmgmt experience @Rovio video entertainment platform pic.twitter.com/xkHVAhSUeW
— Brainmates (@brainmates)
5. huhtikuuta 2014
What is product management? – I might sound like a silly question, but I haven't found a simple yet comprehensive answer for it. Typically the definitions are something like "combination of UX, tech and business" but they don't help you in becoming better at product management. Other sources have long lists of what qualities good or "rock star" product managers should have, which often aren't very actionable. I think the community would benefit from a coordinated effort to try to understand what behaviors make a great product manager and how you can learn to do them.
“Guns don’t kill startups. Features do.” - @therttua
— Ash Maurya (@ashmaurya)
5. helmikuuta 2014
"Guns don't kills startups – features do!" – chasing features, instead of having a very specific Unique Value Proposition (UVP), risks running out of resources (both in startups and big companies)
"Guns don't kill startups, features do!" @therttua at #pcamphki
— Kjell Lauren (@klauren69)
5. huhtikuuta 2014
What is Lean? – about reducing waste, sure, but only in order to increase flow. Read more about Taiichi Ohno's concept of Flow vs Waste. here: http://www.slideshare.net/EmielVanEst/did-toyota-fool-the-lean-community-for-decades
Flow != coding stuff, it is about creating value for the customer @therttua at #pcamphki
— Kjell Lauren (@klauren69)
5. huhtikuuta 2014
Flow != coding stuff – typically, especially in bigger companies, we're used to thinking about flow in terms of SW dev productivity .. however, the flow we should care about is the flow of value to the customer. After all, the flow of customer value is often directly associated with cash flows as well. Thus: flow of customer value keeps your project alive.
Flow is about creating true value between ur customer & ur company, NOT feature chasing or building products @therttua
— Brainmates (@brainmates)
5. huhtikuuta 2014
Eliminating waste is relevant only in the context of flow – this comes back to Taiichi Ohno's point about focusing on value and eliminating waste in order to increase flow.
Getting the value to flow – how do you do it? This is something that doesn't have the "right answer" but there are many approaches to this. Mine is:
Build something that your customer wants (in line with Paul Graham)
..and wants to pay for (or you're fighting an uphill battle)
..a product that's 10X more engaging than the competition (because as a startup you have much less resources for promotion and sales compared to your corporate competition, and
Focus!
So how do you know where to focus on? My short answer is: customer insight. Understanding your customer intimately helps you understand their model of the world and thus you can use your intuition to come up with solutions that resonate even if the customer herself cannot articulate it in advance.
Customer development (qualitative customer understanding, http://www.slideshare.net/venturehacks/customer-development-methodology-presentation) combined with Lean Startup (build-measure-learn, http://theleanstartup.com/) – my suggestion for a starting point in building customer understanding as a Lean Product Manager. My question to you is: "could you test if a product will resonate before building it?"
Tools discussed:
Business Model Canvas (http://www.businessmodelgeneration.com/canvas)
Lean Canvas (https://leanstack.com/)
The Customer Factory (https://www.youtube.com/watch?v=5iq3xDul0JY)
Startup Metrics for Pirates: "AARRR"(http://www.slideshare.net/dmc500hats/startup-metrics-for-pirates-long-version)
Visualizing experiments: The Lean Stack (http://practicetrumpstheory.com/2012/06/the-lean-stack/) or the Lean Startup Machine Validation Board (https://www.leanstartupmachine.com/validationboard/)
The A3 thinking process / the A3 report (http://sloanreview.mit.edu/article/toyotas-secret-the-a3-report/)
..or Ash Maurya's version of it, the Experiment Report (http://practicetrumpstheory.com/2012/06/the-lean-stack-part-2/)
Models for self-organizing teams: Holacracy (http://www.forbes.com/sites/stevedenning/2014/01/15/making-sense-of-zappos-and-holacracy/) or Agile Squads (http://blog.crisp.se/2014/03/27/henrikkniberg/spotify-engineering-culture-part-1)
Lean is about thinking and culture, not about tools! @therttua #pcamphki
— Kjell Lauren (@klauren69)
5. huhtikuuta 2014
And finally: Lean is above all a philosophy, a way of thinking, and adopting lean is about culture, first and foremost. The associated tools might help, but they might also do harm if focused on in a too fundamentalistic manner.
<blockquote class="twitter-tweet" lang="fi"><p>Flow != coding stuff, it is about creating value for the customer <a href="https://twitter.com/therttua">@therttua</a> at <a href="https://twitter.com/search?q=%23pcamphki&src=hash">#pcamphki</a></p>— Kjell Lauren (@klauren69) <a href="https://twitter.com/klauren69/statuses/452339879490646016">5. huhtikuuta 2014</a></blockquote>
<script async src="//platform.twitter.com/widgets.js" charset="utf-8"></script>
"There is no right or wrong, there's continuous learning!" @therttua #pcamphki
Keep Calm and Keep Shipping – The Art of Requirements Triage
Internet startups and big software companies alike depend for their cash flows on shipping products that serve their customers somehow better than their competitors, or otherwise they risk going out of business. With modern agile software development practices such as Scrum you’d think the shipping part is easy. In real life though, deciding what to ship and when is everything but – and that’s why it’s funny the tools to help with that aren’t all that well known.
I bumped into a thing called “Requirements Triage” by accident, when going through Atlassian’s documentation about how to configure JIRA’s workflows. I googled the term and bumped into a PDF of IEEE Computer’s article “The Art of Requirements Triage” (Davis, A. M., 2003).
The three case studies explored in the article resonated immediately: all described familiar situations of teams trying to cope with conflicting requirements and pressure to ship more than possible within the constraints of physics.
Although Scrum training materials make it sound easy to sort the backlog in priority order and execute that business-as-usual – in practice a number of dependencies, as well as different stakeholders asking for different things with tight time constraints make it nothing like it was described on the CSM or CSPO course. That’s why the article was a fresh breath of air with some concrete suggestions for practices (a total 14, no less) to try to resolve these pressures.
In the order of feasibility – keeping track of dependencies
The first insight from the article’s suggestions (not all 14 were home runs for me) was the idea of keeping track of dependencies, either by attaching an attribute to each user story or requirement, or having a separate document that describes viable alternatives for a set of features or stories that can be implemented together.
This is something that is not introduced on Scrum courses, but has a very real implication on the actual prioritization of the backlog: planning releases based on individual stories might go horribly wrong, if certain features rely on other features that don’t seem that important from the user perspective.
Let’s take an example: let’s say as the product owner of a SaaS web app you want to follow the money and focus on monetization with the next release.
So, all the stories relate to enabling your customers to enter their credit card details and purchasing a premium subscription. Unfortunately, you haven’t taken into account that the app has many users per account, and not all users should access the payment information or add and remove users.
So now you have a situation on your hands where an employee of your customer’s company can accidentally remove their boss’s account and all the related data and lock their boss out of the system. Nobody remembered to tell you, the product owner, that it might be a good idea to first implement a permission model.
Combo points – effort dependencies between non-hierarchical requirements
One major tension in Scrum when managing the backlog is in splitting the stories so that they are possible to complete in a manageable timeframe. If the stories are such, that they can be completed relatively independently without regard for dependencies, they most likely cannot be completed in any one sprint, not even close.
On the other hand, if they are split into smaller sub-stories so that they can indeed be completed in one or two week sprints, then they risk losing context and dependencies. Thus, you might end up with prioritizations that might get you the functionality you need, but you end up getting much less functionality than you could if you were aware of the effort dependencies between stories.
When release planning, plan for multiple releases – and then replan
One of the perhaps most counter-intuitive points of the article was that you should always plan for more than one release at a time as it gives you more flexibility.
Why? Because then you have more outcomes than just “can we fit all this into a single release?” – instead, you genuinely get to prioritize the stories, since the ones that don’t fit, then get pushed to the next release(s), and thus stakeholders see how their prioritization affects the release schedules.
The seemingly trivial point I missed – the probability curves
The one point in the article I think I missed was the point about using probability curves to facilitate realism in the scope of a given release.
To my understanding, the point was that based on previous project estimates and actual performance, it is trivial to gauge what the risk level for future releases are, based on their estimates.
Here’s a direct quote from the article: “Collecting the data to support such graphs is extremely easy. I generated [a probability curve] form a table of past projects, with two data elements per project: the original estimate of effort, using the same metric used for estimating requirements effort, and the actual project duration. Once you have this data, creating the graphs is trivial.”
However, the article doesn’t describe the process of creating these probability curves. Thus, my guess is that this could be used, by having this “error factor” in estimates to calculate safety margins for estimates regarding the release.
The hundred dollar question – using group voting to prioritize features
The above picture, which is obviously Benjamin Franklin saying “you ain’t gonna need it!” reminds us that hundred dollar bills can be used as a way for prioritizing features for releases.
A common problem is that all features are equally important at the outset. Thus, the article suggests, group voting mechanisms such as the hundred-dollar test, where stakeholders divide their “money” on different features, and essentially vote, result in some features becoming more important than others.
What I like about this approach is that it has the potential to show all stakeholders how, when taking multiple viewpoints into account; certain features just rise above others in priority.
A lightning rod – finding innovative solutions to marketing vs development problems
The article describes many situations where a marketing department ends up pressuring a product development team to commit to an unrealistic schedule for the understandable fact that a market opportunity window is open only for a certain timeframe.
The article describes interesting solutions to such problems, where the traditional backlog prioritization is not the solution, since marketing has a valid point that if the company ships an incomplete (reduced scope) product even if it’s on time, it doesn’t have the wanted effect on the market. The solution, instead, comes from a novel combination of release scoping and scheduling, as well as pricing and marketing strategy.
The specific example in the article describes shipping an older generation product earlier than competition and lowering prices significantly, until a new generation product is shipped a bit later than the competition, but now it has new-to-world functionality, and the company hasn’t lost significant market share, since it took most of the demand off the market by pricing the older product so much lower than its competition.
They didn’t teach this in school – In conclusion
Although most of this might sound trivial in now that it’s out in the open, this isn’t taught in school or on Scrum courses. Instead the good old “project triangle” of having to fix either scope, schedule or resourcing is the default way of modeling release planning.
That’s why these kinds of more diverse looks at how to do release planning are very welcome. Even if this isn’t a new article, I noticed that none of the ten people I quickly surveyed knew the term “requirements triage” although a handful knew the word “triage” in its original meaning related to disaster relief, and one person knew “bug triage” meaning the activity of trying to understand which bugs should be fixed first.
Requirements triage, in my opinion, is much more complicated, since there are no right answers and it comes much closer to marketing than project management – no wonder the author of the article calls it “a multidisciplinary art that is critical to the success of any product development, yet companies rarely practice it.”
Perhaps it could have a sexier, sports-related name (like Scrum, coming from Rugby), but in its core it is about going beyond the traditional project triangle into the domain of strategic product marketing, in order to get better answers to business owners’ demands than “we can’t ship this product in the time you are giving us”.
I’m not saying it would be easy, but the upside of attempting it has the potential of far outweighing the work going into it that I’m personally going to explore if it could help me in my work.
From desperation to excitement: validating yourself through the brick wall.
NOTE: This is a long post, since the event was quite life-changing for me ... I'm still integrating a lot of the stuff. Running Lean (=actually following the Lean Startup methodology somewhat rigorously) is a bit like living a healthy, productive life: many talk about it, few have the discipline to actually do it on a daily basis.
The investors (Creandum's Andris Berzins, Reaktor Polte's Oskari Kettunen and Founder Institute's Petri Lehmuskoski) at this weekend's Lean Startup Machine Helsinki event said few startups they meet actually are actually living by the lean startup method, and in Finland they've not seen a single one.
Perhaps it's not even useful to require any startup to actually totally measure up to the ideal of being totally lean – like it is not a good idea to try to have 0% body fat – , but still I feel there is certainly a lot of room for improvement.
An end to using "arguing over opinions" as a validation method
An end to arguing – experiments with binary outcomes. Pic by @tlaturi.
Most startup events and accelerators I know of strive for good entertainment (=competitions based on pitching) and perhaps the vanity metric of investment deal flow. Certainly there's nothing wrong with deal flow and good entertainment, but my feeling is they alone aren't enough to make sustainable startups that bring prosperity to their stakeholders in the years to come.
I'm sick and tired of "coaching" startups that rather work on their product for months instead of validating their business (=finding actual customers willing to pay a proper amounts of money for solving a problem with a particular solution), however that's what most of us entrepreneurs end up doing, because it's much more comfortable.
I've nothing against working on products and I love trying my best to help startups, but I feel that building products that nobody want, as well as arguing over opinions about those products are all a waste of everyone's time.
That's why Lean Startup Machine Helsinki (LSM for short) was such a refreshing new concept and after getting some social proof I felt I needed to be a part of it.
LSM Helsinki: Lean for Real
Enter LSM Helsinki, sort of like a hackathon, except it isn't. Like hackathons, teams are formed by people pitching their ideas, but instead of pitching solutions (like a normal hackathon), the LSM way is to pitch customers with problems. Pitching solutions is instantly called out, and the problems (if such exist) are forced to the fore.
Teams at work on the 1st night: brainstorming first experiments.
This time the selection mechanism was that mentors and organizers chose the most "executable" customer/problem hypotheses for the sake of getting right to the point (trying to validate a problem regarding Fortune 500 CEO's over a weekend in Finland is not going to be that useful) by giving out Javelin boards (tool for visualizing validation experiments), and then people gravitated towards the ideas and people they resonated the most with.
After brainstorming their first experiment (again, without a solution, just a customer and a hypothetical problem and a validation criteria to get a binary answer on whether or not this problem actually exists), the team gets out of the building (a classic phrase coined by Steve Blank, and used constantly throughout the weekend) to do customer development (another term coined by Steve Blank) – i.e. exploring the problem with people the team thinks fits the description of their customer – to either validate or invalidate the hypothesis.
Got the scars to prove it?
Knowing about Lean Startup and actually executing it are two different things. Have you got the scars to prove it? Pic by @tuomas.
A lot of people know this process after reading the book that coined the whole concept (Eric Ries's Lean Startup) and can even discuss the subject, but there's a kind of a life changing aspect to actually going all in with it for yourself that shines through.
If you've been in a situation, where you had to admit that your startup is not solving a problem customers would actually pay enough for to let you even cover costs, let alone make you a billionaire, you might have felt enough pain to actually start looking for a better way (a common denominator for a lot of the event's mentors, and even some attendees, btw).
Even corporate employees can join the party – and so they did!
On the other hand – and this is the beauty of the whole thing – even employees from medium-sized and even big companies (mine included) joined the LSM event, which made it that much more interesting to me, since it's not typical to see these people in startup events.
Seeing people without prior entrepreneurial experience getting much further with their idea in a weekend than a lot of startups in accelerator programs – sans solution – was very inspiring. People I've talked with afterwards have said they got a lot out of the event and looking forward to seeing how they could leverage these skills we all learned in their respective roles.
Doesn't have to only apply to teams just starting out!
The Ambro guys giving out samples of their drink on the left and right, @mutru from Flowdock in the middle. Pic by @annikato.
Some new interesting flavor to the event was brought to the event by the Ambro team who – although already working on a food supplement / meal replacement drink for a while now – accepted the challenge and joined the experiment party by running a couple of their own experiments.
The team was originally supposed to just come and do a presentation about their product and run a stand with a possibility for tasting the drink, ended up doing some email marketing / coupon related experiments as well as talking with the mentors.
If nothing else, talking with the Ambro guys proves that existing companies with customers and existing products will benefit a lot from using the same techniques as the teams just starting out (obviously focusing more on the solution and validating optimal customer segments and why they are using the product).
THEY HAVE NO PROBLEM – planning & running experiments is hard!
Running lean experiments with just the customer and problem as variables in the beginning requires a lot of discipline and energy. It's sort of like cold calling, except you aren't allowed to sell, and even if you were, you don't know what you're selling.
"Frustration!" A team that ended up hitting 2nd place in the end, photographed at a moment when they felt they were hitting a total wall after yet another failed experiment. Pic by @annikato.
There were many exclamations of frustration especially on Saturday night (day 2/3) of "THEY HAVE NO PROBLEM!" I guess now we've at least validated that that there is a situation in life where that is a bad thing.. When you have four failed experiments behind you, and you're still hitting a brick wall, the frustration can get almost unbearably intense.
A definite lesson learned is that actually listening to what the customers on the street say is super important, because many of the teams with best progress in the end made pivots based on single data points that from a statistical perspective are total noise. Having the sensitivity to spot them, and the courage and insight to go for the leap are very important in not getting stuck when life gives you the "no problemo".
One such team had the courage to pivot based on a single (however emotionally significant) data point, getting revenue (6€ in coins, to be precise) in the next experiment, and even more in the next, in the course of 24 hours. Althought that might seem small, after hitting the wall for hours, any kind of validation feels like aloe vera for sun burn.
Watching grass grow
Being a mentor or a coach is always hard. It's especially hard to be a mentor for a startup or a team with just an idea, because at the one hand you try not to waste anyone's time when something isn't obviously working, but on the other hand you should not be pushing your own ideas.
Fertilizer burn or a well-placed push out the door? Mentoring is never easy. Pic by @LeanHelsinki.
When you have about 48 hours time to go from a hypothesis to a validated problem/solution fit, there's an additional layer of challenge to get teams to go through as many experiments as possible. When teams invalidate multiple carefully planned hypotheses in a row, frustration and even desperation might set in.
Combine that with the energy drain from talking to tens of people on the street, and there's a risk that the team will turtle up and settle for arguing instead of gathering more data. My first instinct was at that point to push the team to get out of the building.
Fertilizer burn & frost bite
However, sometimes that might be the wrong call. My biggest learnings this weekend relate to sensitivity regarding when to give the team some room to breathe and think things over, when to ask questions and facilitate discussion, and when to straight up push them out the door for more data. No easy answers here, though.
Get out of the building. The Ambro guys + mixed in LSM's own Adam & Eric, as well as me and @tlaturi. Pic by @KimmoKoivisto.
It's like trying to grow a tiny plant pushing through the soil – when's the time to just let it grow and reach for the sun (product/market fit in this case) and when to throw in some fertilizer when things don't seem to go anywhere.
There is such a thing as fertilizer burn, after all.. Or, if you want to use another metaphor, pushing the team out can lead to frost bite if they aren't ready with crafting their next experiment and just end up wandering around with no clear questions or success criteria.
That was actually one of the comments of an attendee: do not try to push a team out if they haven't yet come up with a clear and focused experiment. When I asked "how do I know if it's that or just inertia", he answered (what a beautifully to-the-point answer it was!): "How about asking them if they know what exactly they are going to ask from the customer?" Nothing to add here.
The journey really only starts here
Literally the first 1€ of revenue for this team. Never underestimate psychological leverage. Pic by @RepackOriginal.
The weekend is definitely the best thing that happened to the scene in a long while. More investment money and media attention in the ecosystem are all well and good, but giving people experiences on validating ideas without a single line of code in a weekend – along the lines of the LSM slogan of "what takes you 6 months took me 3 days" – changes the concept of what is possible, and what is needed to start validating a business. What is validated cannot be unvalidated.
Especially the teams that got some actual revenue, I think this weekend has been a very memorable experience – for some it might have even shaken some very fundamental beliefs about how businesses are being built. I don't know if the same can be said about pitching competitions, even if there's nothing wrong with those either.
I look forward to seeing people use these skills in their work (and if you do, please let me know how it went!), be it a startup, a non-profit or even their 9-to-5. I've already experimented with lean at my work for a while now – and with good results. That's why I'm positive that many others will benefit from learning to use these methods.
Winning team: the Receipt boys (@aablo, @rolleh and @SamiHonkonen) plus mentors and organizers. Pic by @tuomas.
So, until next time ... keep calm, and keep validating.
You've most likely heard someone, at some point, claim something like "I just can't learn math, even if I try." I hear it all the time. Even in business school. As a matter of fact, that's how I feel some times.
Many people say the same thing about programming. I personally think programming is easier than math, but I also think has to do with the point I'm going to make.
Recently I've realized something, when I discussed this with people.
"Why don't you get it?!"
Perhaps this is not the only answer, but it seems to resonate with many people and understanding it helped me ahead tremendously. Most often it has to do with the way we think about how learning should take place. See, many people including me, think that learning is about "getting" something. Like "oh, I get it!"
That's why we assess whether we've learned something by asking ourselves: "do I get this?" If the answer is yes, we go to the next thing, and the next, and after the lecture / reading the slides / the book / whatever we feel that we "get it". I also feel that this is partially why some people are told they are dumb if they don't succeed in math.
Learning some subjects might work like this –– for me, learning history (the subject) goes exactly like this. I feel it's like logic – when you understand the motives of different actors on the "stage", it's easy to remember their "lines" – or the events and how they unfold.
"Math, ..and other languages"
However, math, and programming – perhaps languages as well – seem to be different. It's not that much whether you "get it" or not. When you have a blank paper in front of you, even if you "get" how calculus works, it doesn't help you much if you don't know / remember how use the formulas etc.
So this brings us to the points I've discussed a lot recently: first, math is something that you need to practice in order to be able to use effectively. If you're a quick learner, it might stick easily and only a couple of times is enough – in the easier calculations at least.
The danger is, that when you go into advanced math, it might not be easy anymore and if you're not used to doing those repetitive exercises, you might suddenly feel like something is wrong when you don't get the stuff first time.
The second point is, that what's common with math, programming and languages is, that they're essentially all languages. For some, it might be relieving to understand this, if they feel that they are "naturally good" in learning some of these three. On the other hand, if you're terrible in any/all of these, it might also be a relief to understand that the mechanics to learning them are quite similar.
How I see it is that they all consist of some underlying philosophy that helps understanding them, they all have syntax (grammar) that has all these rules and exceptions/gotchas (some more than others), and finally all have lots of things to learn if you want to use them in real life applied situations (vocabulary, API's/libraries, special cases).
"Sit still, boy!"
Now in the end, all of this is just my personal ramblings. The important part comes here: we all can learn math, programming and languages – we just need the right tools.
The problem is that the traditional school system is geared towards a certain type of people who have the patience and the motivation to "drill" through thousands of exercises.
Unfortunately, not all people are like that. You might call it ADD/ADHD, I just think people are different and people were certainly not shaped by evolution to sit still in class.
The other problem is that because the educational system has been in the 19th and 20th century, we just didn't have the in-depth understanding of human behavior to create the best possible ways of learning. Only recently this has started to change, with the advent of such programs as the iTunes U (http://www.apple.com/education/itunes-u/), Stanford's free online course pilot (http://news.stanford.edu/news/2012/march/online-courses-mitchell-030612.html) and most recently, MIT & Harvard (http://www.edxonline.org/).
"The biggest advancements in learning technology seem to come from outside the traditional education circles"
The funny thing is, that the more interesting programs have come outside of the traditional educational community. My two personal favorites are the totally free Khan Academy (http://www.khanacademy.org/) and the not-so-free CodeSchool.com (http://www.codeschool.com/). There are others as well in the same category (TryRuby by Codeschool, http://tryruby.org/levels/1/challenges/0; Codeacademy, http://codeacademy.org/ etc.)
These are very different from many other methods of learning, because they try to leverage game mechanics to interactively reward users after completing small chunks of exercises.
For me, Codeschool is the absolute best way (at least to date) to learn programming: short screencasts that also act as rewards and small chunks of exercises that make sure I can actually reproduce the code before it lets me advance. This forces me to actually do the exercises – and the following videos feel all the better, when I have worked hard for them.
Khan Academy also has exercises, and I hope to use that in the near future to improve my math skills. There is also something similar for learning languages (such as http://www.rosettastone.com/), but I haven't found one that would actually be interesting enough to complete a whole course. Obviously there's still a lot to be done.
"Based on my automatic assessment of your skill level, here's your personalized course in ..."
I believe the next major step in making learning more efficient (now that the basics have been nailed) is using machines to understand a person's individual proficiency in each of the areas of a skill that is to be acquired (example: in order to be able to do Ruby on Rails programming, you first need to also understand HTML, CSS, Ruby, basic unix skills, etc. etc.), and then tailor an experience that constantly pushes the envelope and keeps things interesting –– constantly with the goal of proficiency with that skill in mind.
For me nothing is more frustrating than doing exercises that require a lot of work but are not that hard. On the other hand, I'm willing to work a lot if I feel that an exercise will give me a skill that enables me to do something of value that I couldn't do before.
Oh, and of course there can be a lot of other reasons for why people think they can't learn math – but I bet that after finding fun and effective way to learn, many of them go away.
Protip: beware the obscure "iPhoneselect" (aka Getting iOS and Google to play nice together)
Having fought a lot of times with iPhone/iPad + Google Apps (Gmail / Calendar) and all that jazz, I thought I would compile a "protip" about this so that at least perhaps a couple of souls and be saved from the dark moments I had with all this.
1) Setup your iOS device
First, you need to of course setup your iOS device correctly, which happens from the settings app on your iOS device, from the Emails and Calendars pane. From there you can either choose Google or Exchange and enter your credentials. I think the difference is that if you choose Google, iOS will give you the "archive" button. This should be fairly straight forward –– if not, the basic help docs found from Google (http://support.google.com/mobile/bin/answer.py?hl=en&answer=138740) will get you through.
2) Setup Google Sync
However, the biggest problem source is on the Google side: you have to set up Google Sync to get things working.
So, take your device, go to m.google.com/sync (you need to do this on your mobile iOS device!)
First catch: you need to make sure the language is set to English (US); other languages might work, but they also might not and this was a huge source of frustration until I understood it. Only then you will see the "Sync" button appear.
Next, if you have Google Apps Premium, you need to click the button which says "Google Apps user? Tap to configure for your domain.", which is below all the other buttons.
Now, you will have a Sync button on a green background, which will enable you to sign in with your Google Apps Account.
Now you can manage device settings and select, which calendars you are allowed to sync to your device.
3) The real catch: Setup Google "iPhoneselect"
Final, and the most obscure thing: even after setting up Google Sync, you still need to go to www.google.com/calendar/iphoneselect to choose, which calendars will be synced to your device. This also works for the iPad. Some calendars just cant be synced, such as week numbers and holidays.
Not knowing that there is this final third step made me go furious until I googled through multiple forum threads.
Spells of Rails magic – quick recipes for getting started w/ your first Rails app
When we first start learning new languages, we try to remember phrases to work with, such as "Qu'est-ce que c'est?" (French), and then break them into pieces while trying to understand why they work like they do. Same goes with learning Ruby & Rails: to get started, we need some basics we can start tweaking bit-by-bit. Here's a set of those recipes.
Before starting, you need to have Rails 3.1 installed on your computer
..or whatever is the most recent version. That's a bit tricky and differs on each platform, so I won't go into that here. The folks at RailsGirls did a great job in assembling installation instructions for each of the most common platforms: http://railsgirls.com/install.html
Creating your first Rails project; the command line interface (CLI)
The next oddness for newbies is the fact that you have to use the command line interface (also known as Terminal in OS X and Command prompt in Windows) a lot – and you thought that text-based UI's were a thing of the past..
Here's some resources to better understand how the CLI works:
*OS X
*Windows
*Linux
So, fire up that command line and navigate to a folder you're comfortable creating a folder in (usually, it could be something like /home/Myusername/Documents/). If you don't know where you are, try the
pwd -command (print working directory; in the Windows CLI you could use echo %cd% or just cd), which will print out the directory you are in.
To list the contents of a directory, just type ls or in Windows dir.
To move between directories, use the cd command. You mostly use it with some parameters, such as "cd subfolder" (when you want to go into a folder called subfolder or "cd .." if you want to back down to a parent directory.
Use the mkdir command to create a directory. For instance, if you want to create a directory called "Rails", you would type "mkdir Rails". If you were in the folder "/home/Myusername/Documents", the created folder would exist in "/home/Myusername/Documents/Rails".
Creating the Rails project
Figure 1: Runnin "bundle install"
Once you have Rails along with all the required dependencies installed, you can verify this by typing "rails --version". The CLI should respond with something like "Rails 3.1.1" If not, please consult the RailsGirls installation guide above!
So, let's imagine you've created a folder in /home/Myusername/Documents/Rails, and you want to create a new Rails application.
Start with rails new myapplicationname. Notice, that you should not have any whitespace (" ") in your application name, otherwise you will end up with some unexpected results. So if I were to create an application for listing skateboarding spots around the world, I'd go with something like rails new spots. The shorter and descriptive, the better (in my opinion).
Now you should be presented with something like Figure 1 and after the bundle install has finished, something like Figure 2.
Figure 2: Rails project successfully created
If you get something else than "Your bundle is complete!", you have a problem in your Rails installation and should again consult the installation instructions above.
Testing the Rails development server
Before we get to actually creating stuff, let's see if we get our Rails server running.
Type
rails server or the shorthand rails s in your project folder, and you should get something like:
Figure 3: The Rails server accepting requests in port 3000
What you should understand from this is that now you have a lightweight WEBrick development server running in the CLI window and accepting requests at port 3000. Now, when you go to port 3000 on your local computer (or localhost), you should see something like this:
Figure 4: A successful Rails setup running at http://localhost:3000
Another thing you should understand is that when the WEBrick server is running in your CLI window, you cannot do anything else with that particular window. You need to create a new CLI window or tab in order to continue working. Also, when you do create a new tab or window, it will most probably default the working directory into something else, and then you'll need to use the ls, dir, pwd and/or cd commands, depending on your system and the directory you are in.
To close the server down, use the key combination of Control + C.
Creating your first scaffold
A technique known as scaffolding, in the context of Rails projects, means that Rails creates a set of filed for you that you can start tweaking. Later, when you become a better programmer, you most probably don't need the scaffolding anymore. However, as learning through tweaking code is easier than trying to create everything from scratch, scaffolding is probably the most convenient way of getting started with Rails.
It will give you the tools to maintain (create, read, update, destroy) a list of a certain type of resource of your liking, such as restaurants, dogs, cats, or whatever. Check out the example below to get a concrete understanding of what the resource can be.
Among other things, the command rails generate scaffold Modelname attribute:type creates a Model with a controller and a set of view files (index, show, edit. Example: you want to create a resource named "City", which means you want to maintain of a list of cities.
Then you would use the generate scaffold command like this:
Figure 5: rails generate scaffold City name:string population:integer founded:date
Which means you are going to list cities and keep track of their names, populations and date founded. In order to get this running, you still need to migrate the database. This means updating the database according to a migration the scaffold created for you. The function of the migration is to keep the structure of the database and the data in it sync with the code you are creating. Also it provides you with the means of rolling back the changes you just made if you find out that they were not what you actually wanted.
The migration is done with the command bundle exec rake db:migrate
Figure 6: bundle exec rake db:migrate
Now, give you still have your WEBrick server running in another tab or window, when you point your browser to http://localhost:3000/myresourcenameinplural , for instance http://localhost:3000/cities, you should see something like this:
Figure 7: Listing cities
Yay! Now you have your first Rails application going.
Understanding how Rails works: The MVC architecture
Before reading further, check out the awesome Bentobox model by Linda Liukas (RailsGirls), which clarifies all these different terms and opens up the top-level architecture or technology stacks of any web application (also contains concrete examples of apps like Etsy or Foursquare!)x
Rails is built on a design patter called Model-View-Controller (or MVC). There are alternative design patterns as well, but MVC seems to be one of the most popular ones out there.
What the MVC means is that the application is split into three main parts: the model handles communication with the database (which is actually a separate part of, as you can see from the Bentobox model), the controller handles incoming HTTP requests from users' browsers or other computer systems, as well as showing the right view for each request. Finally, the views are templates, where the dynamic data from the model (as instructed by the controller) is inserted, after all kinds of calculations and other logic.
In other words "Models do the grunt work, views are the happy face, and controllers are the masterminds behind it all." -Betterexplained.com
The reason to use the MVC pattern is to keep things nice and tidy, so that everyone developing the app knows where to find each kind of code. What you need to understand from this is that you should not do heavy calculations in the views or controllers, but in the models. The controllers are used to prepare the data for different uses. The views should be "dumb" and just present data given to them by the controller.
Start to modify your application
The easiest way to start developing your application is studying the HTML/ERB files found in the views directory. (myprojectname/app/views/modelname/).
Figure 8: the views folder with index.html.erb
In Figure 8 you see the contents of the views/cities/ folder. Inside, you'll see different files with descriptive names. These filenames are in sync with the cities controller and eventually the City model, so you cannot start changing the names without breaking stuff. Let's study the contents of index.html.erb inside the cities view folder instead!
Figure 9: Cities index.html.erb file with the dynamic listing highlighted
Above, in Figure 9, you see the contents of the index.html.erb created by the scaffold command we used earlier.
Some of the file is pure HTML, some of it is ERB (or Embedded RuBy). The ERB parts are signified by either <% ruby code here %> or <%= ruby code printing out something here%>. HTML is just <start tag here> or <single tag here /> or </end tag here>.
The idea is that you can dynamically create HTML by using the ERB templating engine. As a result, you can say things like <%= city.name %>, which will print the name of each record of cities in the database.
You could start by editing the non-dynamic parts of the HTML.ERB page, for instance changing the heading of the page (<h1>Heading here</h1>).
Where from here?
Now that you have created your first scaffold, try to tweak the HTML, and if you're in the mood for it, futher explore the possibilities of using the dynamic ERB templating engine, for instance by playing around with Ruby's string methods, such as <%= city.name.reverse %>, which will print the name field out in reverse. Great for finding out palindromes!
More resources for autonomous learning
If you want to proceed on your own, good starting points are, for instance (please suggest more in the comments!):
*The official Ruby on Rails API
*Why's Poignant Guide to Ruby
*RailsCasts
*Nodeta's rich front-end to the Rails API, APIdock
*Learn Ruby the Hard Way
*Codeacademy
*TryRuby
*The Pragmatic Programmers' Rails book, available as an PDF eBook
In the next episode..
Next, we'll go into actually programming some logic. Thanks for reading!
Whose advice should I listen to? – Building relevant knowledge about Entrepreneurship
Caption: This reminds me of the data-information-knowledge-wisdom pyramid.. Source
If what I've heard is true, there was a time when Steve Blank and Eric Ries were just guys who had their opinions about startups like the rest of us. Since then, they have become the leading authorities in startup marketing. Will they stay like that forever or will new people become authorities after them with new, counterintuitive ideas (in today's terms)?
What interests me is how people become authorities in some field or another, and how do I know if a random guy telling me that I should do as he says, is the future equivalent of Blank or Ries. How can we build new knowledge in a way that embraces change and new ideas –– and still makes it possible to teach a certain paradigm (like the learn startup movement seems to be right now)?
Promised land of false prophets?
Why is this important? Well, if we want to continue building successful startups in the future as well, we should also be able to learn about the changing world around us. The problem, as I see it, is that people constantly promote new ideas and as a founder it is sometimes hard to see, whose advice I should take seriously.
As an example, if I go and ask a professor of entrepreneurship (might also apply to other countries, even some parts of the US) what are the first steps in building a company, he/she might start explaining about writing business plans (opposed by Blank in the context of startups), raising funding (opposed by the lean startup ideology) and so on. And to make myself clear, this is a purely hypothetical situation and changes are slowly starting to take place as Blank & co are getting more and more mainstream publicity.
Wrong tool for the task?
The problem here is that the hypothetical professor is talking about a certain kind of entrepreneurship. Blank said in his recent keynote here in Finland that business plans are good for extending an existing business but lousy for searching for a new business model, because there are so many unknowns and assumptions. So it's not that the professor is "lying", but he's just offering the wrong tool for the task, and might not know better –– at least from the viewpoint of people who believe the lean startup way is better to succeed with a startup.
And why don't people know better? I don't know, but perhaps it has to do with the way information becomes a paradigm –– usually, but not always, through research and then teaching. The other way is through trial and error, i.e. someone just believes enough in the information and starts getting results. Sort of like doing customer development on entrepreneurship best practices..?
Could we have the best of both sides?
Although I'm no researcher myself (perhaps I'd like to, but I like doing startups more), I still believe in the scientific method and verifying information and then passing it on to others making it possible for the rest to stand on the shoulders of giants, as the saying goes.
The little amount I've observed how entrepreneurship research is done here in Finland, the problem seems to be that the researchers are not founders themselves, and that's why even the hypotheses seem to be a little bit old fashioned. I guess that is slowly changing too, but still I think the best possibility to get new information is in the front lines.
Taking the justice into their own hands – the Startup Genome project
What pleases me a lot is initiatives like the Startup Genome project, where startup founders have decided to start gathering relevant information themselves. However, when they published their first report, someone complained that it wasn't scientifically rigorous.
This is why I believe founders and the science community should work more closely together. The founders could help with finding relevant hypotheses and the researchers could handle the rigor part like it ain't no thing. Ever better would be, of course, if founders could become a part of the science community and actually lead the way in finding new interesting subjects for research.
Where should we go from here?
I haven't spent a lot of time discussing this idea with different stakeholder groups –– and that's partly why I decided to post this to get some feedback –– but my own experiences with providing my opinions about research straight to the researchers have been positive and I would like to see more of this kind of co-operation.
The first actual startup research in Finland I heard about was by a guy doing his PhD (if I remember correctly, he was doing research about failed web 2.0 startups, so there's similarity to be found with the Startup Genome project) to the Turku School of Economics, and the discussion with him lead to the idea of this post.
Comments, experiences, action steps?
Do you have experiences about bringing founders and entrepreneurship researchers closer to each other? How would you go about getting the show on the road? Other comments?
