Blog —

How Pieter Levels Builds Minimum Viable Products

Pieter Levels builds Minimum Viable Products that he calls Startups

Pieter Levels builds Minimum Viable Products that he calls Startups

Core ideas and learnings from Pieter Levels researching and collecting publications from and about him.

Prologue

I read through all the popular posts by Pieter Levels. He made 12 startups in 12 months, and I collected the core ideas, key outcomes and main learnings.

In a list. With bullet points. Organized in categories. Where applicable, I changed his notions into the imperative, for readability and attractiveness – note that it does occasionally change the way he said in his posts. He usually is pretty cautious and reflective in his notions. Things can be repetitive which is intended so you remember.

All in all, it’s the kind of lecture notes you did while in class. Edit the list if you feel the urge.

Easy navigation

  1. Personal drive
  2. Process
  3. Ideate
  4. Prioritize
  5. Launch
  6. Validate
  7. Marketing, Market fit
  8. Build: Community
  9. Build: Make Mindset
  10. Execute: Keep it small (to start)
  11. Manage
  12. Automate
  13. Code
  14. Code: project folder structure
  15. Design
  16. Very technical
  17. Extras
  18. Epilogue
  19. Sources

Personal drive

  • start with projects that get you excited so will actually continue doing and finishing it
  • stick to a field for 5-10 years so you get really good at it
  • don’t be scared bigger companies who are already successful: just because their final product looks and works super polished for the customers, behind the scenes it’s a battlefield
  • make it look as if it works smoothly (for the people using it)
  • everybody can do it, don’t be afraid of thinking you can’t do it because you probably can
  • you can only help yourself, nobody else can do (except for doctors, maybe)

Process

  1. when you have the idea, visualize it in your head (when you are visual person) and draw on paper first
  2. create a mockup in Photoshop, Sketch, etc.
  3. use http://www.stocksy.com for stock photos
  4. make the visualization look great to get the feeling across
  5. write the front-end code (HTML, CSS, JS) in your favorite editor, e.g Sublime, and make the site responsive
  6. use Chrome’s new emulation feature to see how it looks on mobile
  7. slowly let it evolve into adding back-end features (e.g. in PHP)
  8. Talk to users. Develop with and for them. It works. (as learnt through Eric Ries)

Ideate

  • have a big backlog of ideas
  • we all have the same ideas, it’s just about executing them
  • think about the problems you wanna solve – your own problems, less trivial problems, Western world problems, problems out your world (or bubble)
  • start off by solving your own problems / scratch your own itch
  • expose yourself to the world and its market forces to figure out what you need to do

Prioritize

  • if you can’t do everything, only do the important stuff
  • prioritize requests (it can mean to ignore them)
  • don’t use email, it’s distraction if you enjoy building
  • allow yourself to work on things that have personal momentum (flow) for you so you can do them active instead of reactive
  • do active work instead of reactive

Launch

  • build stuff, tell a story with it, and keep launching
  • there’s not one launch; launch every day by adding new features, engaging your audience
  • iterate constantly
  • startups are a constant iteration
  • if you’re not iterating, you’re dead

Validate

  • validate an idea when you can
  • (if possible) validate an idea before you build
  • ask Twitter about what to build
  • see if basic stuff works, then grow it
  • you finish faster because you build less
  • remove the constant drive for perfection

Marketing, Market fit

  • write about what you do
  • build a product with a story baked into it
  • start out with a good story (narrative) to get press coverage
  • be critical of yourself
  • build a product that is significantly different or better to get press coverage
  • if you can’t describe your product in one sentence and in that sentence get across how it’s different or better, then it’s probably not
  • look what startup (in Levels’ definition) takes off and continue building
  • a startup delivers a new product and grows it fast
  • don’t pursue what is not monetizable
  • if you don’t a get market fit within the month you launch, consider it failed (remark: this is of course very radical and related to Levels „12 in 12“ project)
  • do in 1 month: small web apps or websites that have some functionality, try to monetize them as fast as possible, get a market fit and see if it works
  • if this app or website fails in this month, consider it failed
  • continue building other apps or website until one mvp takes off
  • the big vision happens after you find a market fit with your MVP
  • there’s a lot of market in your niche for your startup, start your one-person company and eventually hire a contractor or employ them later

Build: Community

  • create an engaging community around your product from day one
  • do it on your site, or in your app, or on other platforms, like Twitter or Slack, or even in real life, by letting people organize meet ups – it not only helps your own product’s engagement, it can also be good for real-time user research and launching new products or features to your audience
  • don’t necessarily have your community by completely tied to your brand, keeping an informal community around topic very loosely tied to your product is fine
  • it helps you and people too

Build: Make Mindset

  • do stuff, don’t get distracted how to do stuff
  • make stuff that works and doesn’t break
  • do things the wrong way, it doesn’t matter, because it will still lead to something
  • do cool stuff for people, and then do cool stuff for more people to help them a lot
  • do something / build stuff + finish it – that will position yourself already ahead of 99% of the people
  • when you do nothing, you figure out exactly nothing
  • in the long run build more stuff that has a wider impact

Execute: Keep it small (to start)

  • be a minimalist perfectionist to finish and ship things
  • start small first and slowly build bigger things when you’re not experienced
  • don’t build things big immediately
  • don’t build on your product for 2 years and launch then
  • build small products and build many of them
  • build simpler products, so you can finish it easier as well
  • finish your MVP and keep it minimal
  • ship your products fast(er)
  • start startup as MVPs using Eric Ries Lean Startup approach

Manage

  • don’t get an office, you can work from anywhere
  • do things that matter now, avoid a (long) todo list because by the time you arrive on this item it will be outdated
  • figure out a work flow that works best for you
  • use Trello to get shit done
  • in Trello have a list for this year, this month, this week, today and now; when you go do something drag it into the „now“ list to give you me an immediate sense of action and knowing what to focus on
  • when you finish the task, drag it to the list on the left which holds all completed tasks for this week; at the end of the week, move the entire list out of the „to-do“ board to the „finished“ board
  • make todo list with pen and paper in a mind map, it’s closer to how the brain works (if you don’t like Trello)

Automate

  • create a product that gives you regular income (cash flow)
  • create product that give an automatic income with you doing something

Code

  • you don’t need to be passionate about programming to make stuff
  • don’t use framework except for jQuery
  • keep your code clean and fast
  • use DRY KISSes: Don’t Repeat Yourself and Keep It Simple Stupid
  • re-use functions or pieces of code you wrote before
  • don’t use an IDE, use a text editor like Sublime Text 3 to code
  • use CodeKit to compile/minify JS and SCSS files
  • make your code easily readable by other coders to refactor and/or scale it

Code: project folder structure

  • create a project folder structure
  • /_assets – everything that shouldn’t be on the server, pre-dev assets like mock ups in Photoshop and Sketch of the interface and logo designs
  • /assets/ – all public asset files, pretty much everything used by the front-end (CSS for styling, JS for client-side scripting, images in PNG etc.) – all JS/CSS files are pre-processed from the /app/ folder
  • /app/ – includes all front-end (SCSS, JS), back-end code (PHP, Node.JS) and also the server configuration in the nginx.conf file that Nginx uses
  • use CodeKit to monitor the /app/ folder and automatically pre-process/minify/compile the SCSS and JS files to the /public/assets/ folder
  • /lib/ – includes all back-end server-side libraries and stuff I didn’t make myself and don’t want to edit
  • /workers/ – includes all app files that are scheduled and do stuff in the background by cron jobs
  • /logs/ – includes simple .txt files to log stuff
  • /data/ – includes all data used by the app
  • using JSON text files instead of a database system – but if you’re getting sensitive user data, secure it in a more decent fashion

Design

  • make minimal user interfaces
  • don’t fill a site with functionality from top to bottom

Very technical

  • have an own server hosted by Linode and have one virtual private server (VPS)
  • register a domain with NameCheap and use their FreeDNS to add DNS entries to point to your Linode VPS IP address

Extras

  • be unified with your tools to really make anything ^_o
  • avoid physical low-scale stuff

Epilogue

Researching, analyzing and writing down his public notions I found his expressions of doing similar to what the Buddhists say to „stop thinking“. Interesting analogy since Levels is also very much a fan of (South East) Asia.

In the end this could serve as a manifesto. Anyone eager to create this a textually and visually manifesto? I’m thinking in the style of „Holstee“ or „Maptia“.

Sources

Also published on Medium.

Did you like this post? Tell me on Twitter what you got out of it or what you were missing.