Save Your Next Project Before It Begins

picard.gif

“It is possible to commit no mistakes and still lose. That is not a weakness. That is life.”

-Jean-Luc Picard

Wise words from a wise character.

With a new project, how can you increase the chances only fate determines your project’s success? In other words, how can you eliminate some big mistakes in the first place?

Use two tools: The Amazon Press Release and The Pre-Mortem

1) Working Backwards / The Amazon Press Release

The first exercise is to write the press release that you might publish later after you’ve built the product. It’s a 1-2 page living document which outlines the basic important things about your product. Speak simply and to the user – I recommend “Oprah speak”, the king of language Oprah might use. Include:

  • the product
  • its users
  • what problem you’re solving
  • how they currently solve it
  • how your new solution is better

This short document should be the guiding force to refer to during the lifetime of your project. It will help the product team, the marketing team, the development team, and everyone else be on the same page from the very start. It’s a simple, powerful, useful exercise. Do it! The actual document will be useful, but the process of creating it is even more valuable. Make sure the whole team is involved here to improve organizational alignment and buy-in.

More information here:

2) The Pre-Mortem

The second tool is another relatively short exercise, ideally performed as a team.

For this one, it’s even more important to get the whole team of stakeholders and contributors involved.

A pre-mortem involves thinking through the project, potential pitfalls, and how you can mitigate them before you even start. People can surface potential issues early and make plants to overcome them.

Some guiding questions:

  • Why is this project going to fail? What might go wrong or lead to issues?
  • What about the team will lead this project to fail? What might go wrong or lead to issues given the people involved? What can you do to mitigate this risk?
  • What about the product will cause the project to fail? What might go wrong or lead to issues given the product? What can you do to mitigate this risk?
  • What about the market will cause the product to fail? What might go wrong or lead to issues given the market? What can you do to mitigate this risk?
  • What about the technology will cause the project to fail? What might go wrong or lead to issues given the technology being used? What can you do to mitigate this risk?

More information here: https://hbr.org/2007/09/performing-a-project-premortem

The two exercises are straightforward and amazingly powerful. The handful of hours they take will be some of the best time you spend on a new project / as you build a new product. These two tools will help create clarity and bring to the surface known issues. By using the Amazon Press Release and the Pre-Mortem exercises, you increase your chances of success.

Engage!

Why are there so many tools in modern web development?

A lot of tools exist in modern web development. In many cases, a simple static site is all you need to make, and basic tools such as a text editor are all you need to build it (without creating new problems!). But sometimes you do need more – you’ll have a million users a minute and the site needs to be interactive. The web development ecosystem has many useful tools to use, including Babel, npm, and frameworks such as React/Vue/Angular.

This article from Victoria Kirst talks about the traditional web development workflow, and how different modern tools came about to solve different problems.

https://www.vrk.dev/2019/07/11/why-is-modern-web-development-so-complicated-a-long-yet-hasty-explanation-part-1/

Happy building!

Useful CSS Trick to Keep Elements in Place on Hover

By giving elements a transparent border as a default, and changing the color of the border on hover, you can avoid moving other elements around the page when a user hovers over elements.

Example: https://codepen.io/rudimental/pen/aMZaBV

Do this:

button {
  border: 2px solid transparent;
}

button: hover {
  border-color: black;
}

Not this:

button:hover {
  3px solid black;
}

Now your other elements won’t move when a user hovers over the button.

Email To My Brother – A Crash Course on Product Development

Let me talk about a hypothetical situation – say you’re my brother, a brilliant guy (scored 180/180 on the LSAT) who has dabbled with algorithmic trading, and practices law by day. An acquaintance introduced him to somebody who wanted a new SaaS product for their large, finance-related online community. Due to his combination of skills in law, finance, and programming, my brother has the chance to deliver an exciting new product. The only thing left to do: learn how to build and deliver a product from idea to launch to iteration.

He wanted a crash course in product thinking and product management to learn useful skills and processes around developing a software product. He wasn’t looking to start a billion dollar, high-growth startup. He just wanted to build something to satisfy his users’ needs, and something he could deliver. He was crunched for time, because his new contact wanted to keep the conversation going at a fast pace. Here’s what I told him:

Don’t build anything, yet

  • Do the Amazon style press release here
    • This document outlines the basics: the product, its users, what problem you’re solving. It should be the guiding force to refer to during the products life. It’s a simple, powerful, useful exercise. Do it!
      • It will be helpful to do the Amazon press release with your new contact, so you’re on the same page about the big picture.
  • Validate, validate, validate
    • Normally I’d follow this strategy here. Much of it is still applicable to satisfy your end users. But in this case, you also have to understand what your stakeholder (the new contact) wants you to build. What problem he’s trying to solve, how, and what he thinks of the market (his users).
  • Read The Lean Startup by Eric Ries – ideally the whole book. It’s foundational in startup land on process and how to maximize your time and effort by optimizing for learning. By testing small hypotheses, you will avoid spending lots of energy on paths that lead nowhere. You will do as little as possible to learn as much as possible, which is faster, cheaper, and easier in the long run. Because you’re crunched for time, read:
  • NOTE: These steps might take weeks or months

OK, now you’re ready to start building something, kinda

  • Build an MVP
    • The smallest, shippable useful thing you can make to test assumptions, validate ideas, and get feedback. You’re like a scientist here. You will not and should not try to build or ship the total vision, a complete thing. What you ship does not solve all the problems and pain points. It might be a video, a landing page, or an ad. Read this: https://scalemybusiness.com/the-ultimate-guide-to-minimum-viable-products/ Your goal is to learn quickly, so you get to building the right thing quicker. So ship something small to learn.
    • Internalize this image:crop-minimumViableProduct
      • It’s amazing. Look at it again. Your MVP can’t just function ok and be ugly. It has to have a little of everything – functionality, usability, beauty. Again, you might not need to be building anything substantive yet. It might make sense to build a video, a landing page, an ad, or mimic a functioning service when you’re the actual person making it all work. You’re MVP might not have much in terms of function or usability or looks – it’s their so you can test assumptions, learn, and get feedback.
    • What’s an MVP? The smallest thing you need to launch. “So what’s the minimum you need to launch? We suggest startups think about what they plan to do, identify a core that’s both (a) useful on its own and (b) something that can be incrementally expanded into the whole project, and then get that done as soon as possible.”
    •  A minimum viable product is “that product which has just those features and no more that allows you to ship a product that early adopters see and, at least some of whom resonate with, pay you money for, and start to give you feedback on”.
  • Keep validating (figuring out assumptions, hypothesizing, testing) 
  • Keep referring to and refining your Amazon press release
  • NOTE: These steps might take weeks or months

 

OK, now you should continue building, shipping, and iterating

  • This image is so great, it’s worth looking at again and again. Now, if you already built step 1, build steps 2-5, starting with 2. If you haven’t, build step 1:MVP
  • Similarly, if you already build step 1 here, build step 2. If you built what was in the thought bubble, now build step 1:

Bonus

  • Read Rework by Jason Fried and David Heinemeier Hansson.
    • Each chapter is 1-3 pages with a picture. It’s not just beautiful as a model for a book, this makes it super useful for readers. This book gets to the point, each and every page. You can read it in bits and pieces – revisit it early and often. I don’t agree with every single chapter, but it’s filled with great ideas, and it’s thought-provoking.
  • Bonus links on MVPs
  • Bonus mantras from Y Combinator (a program that helps companies succeed, mostly software companies)
    • Make something people want.  You can screw up most other things if you get this right; if you don’t, nothing else will save you
    • Do things that don’t scale
    • A small number of users that love your product is better than a lot of people that like your product
    • Solve your own problems
    • Release early and iterate
    • You make what you measure

Key takeaways:

  • Approach things like a scientist. Identify assumptions, make hypothesis, and test them. Validate or disprove them.
  • Try to maximize your resources by validating early and often. Break things down into small, testable pieces.
  • Understand what a Minimum Viable Product is, and build it. Cut away the excess. Then cut away more. Maybe now it’s the MVP. Test it and get some feedback.
  • Build something people want. Give it to them so you can get feedback. Use that feedback well.
  • Talk to users frequently

 

Best of luck!

Tiny, bootstrapped, and highly profitable

Yesterday I read a great post about DistroKid, a music distribution service I use.

imgres.jpgz

DistroKid lets musicians upload unlimited songs to digital services and stores such as Spotify, iTunes, Pandora, and 150+ others, all for $20
. It’s simple. It’s affordable. And it’s a valuable service to its users, as shown by its popularity and their consistent praise.

Philip built the profitable company from scratch, running lean since the beginning. He was the only person doing everything for many years. Now there are 2 support people to help Philip, who is still the sole developer.

DistroKid wasn’t Philip’s first project. He was famous for F*cked Company, as well as many others. Philip leveraged the community of musicians from a previous project to help DistroKid succeed. Having an engaged community, even if small, helps you succeed. It takes effort to build, but truly helps.

DistroKid also wasn’t the first digital distributor – CD Baby and TuneCore are two other big players, and there were several others. But his is smaller, cheaper, and a better-value. Philip didn’t take VC money, so he has no pressure to have a huge exit. This allowed (and forced) him to run as lean as he wants, which he has taken to an impressive extreme.

To understand the company more, here are some numbers from his article:

  • 500 new albums uploaded every day
  • 2,100 new songs uploaded every day
  • 100,000+ artists
  • 250,000 albums uploaded since launch
  • 1.2 million songs uploaded since launch
  • $2 million paid to artists this month
  • $17 million paid to artists since launch
  • 3 billion streams

How do they do it? By automating everything. “DistroKid has dozens of automated bots that run 24/7. These bots do things that humans do at other distributors. For example, verifying that artwork & song files are correct, changing song titles to comply with each stores’ unique style guide, checking for infringement, delivering files & artwork to stores, updating sales & streaming stats for artists, processing payments, and more. These are the reasons why we can charge less (lower overhead) while delivering to stores faster & providing more features (almost everything is automated).

Some lessons from DistroKid, which will apply to many products:

  1. Building something people want paves the way to a profitable business
  2. Building and growing your community of users is key
  3. Leverage previous communities to help grow your new user base
  4. Automate what you can – it keeps costs down, keeps things fast, and can help to create a good user experience
  5. Laser-focused products can be understood easily by people
  6. An affordable, better-value service, can beat more expensive competitors, even if they have more bells an whistles. Especially if it has a better user experience.
    • There are different position successful products can have. DistroKid’s success is fueled by being a cheaper, better-value service, even if it has some missing features (e.g. no vinyl service)
    • It’s possible (and in many cases, easier) to do this without taking investment money – otherwise you might have pressure to grow huge and create a big exit, possibly leading to the implosion of your company

A bootstrapped, profitable, lean company that users love, building something people want.

As a fellow drummer, product person, and developer, DistroKid is an inspiring success.

giphy.gif

Quick, Simple Python Server

imgres.jpg

A small tip that comes in handy for local testing and development – run your own Python server in 1 terminal command.

If Python is installed* (and it is on Macs by default), go to the directory containing the files you want served, and enter the following in your terminal:

python -m SimpleHTTPServer

By default the files will be served on port 8000. In a browser, go to localhost:8000 to have some files served up. Mmmm, files.

That’s it! You have a server running locally.

If you’d like to change from the default port to another, add your preferred port number after the command, e.g.:

python -m SimpleHTTPServer 3000

Your files will be served on port 3000.

Congratulations!

 

* Check with python –version in your terminal

Learn more:

http://www.linuxjournal.com/content/tech-tip-really-simple-http-server-python

http://www.tecmint.com/python-simplehttpserver-to-create-webserver-or-serve-files-instantly/

TokBox – Building things on the Product Team

tl;dr I’m happily part of the product and growth teams at TokBox, working with the marketing team and others on efforts to help the company. I talk about what we do and some projects I’ve worked on. I enjoy being on the product team and dealing with the challenges that product teams face, balancing the future and the present.

What is a TokBox?

Time has flown by since last summer! I started working at TokBox over a year ago. It’s the premier  WebRTC platform company. We make it easy for developers to integrate video into their sites and apps. This means its easier for developer to build something like Skype, or Google Hangouts, or Facebook Live. Our customers range from side projects to massive companies across industries (in education – Duolingo, Chegg, Minerva; in finance and professional services – The Royal Bank of Scotland, Esurance; in entertainment – Fox Sports, Major League Baseball; and hardware and software companies like Double Robotics and Mozilla).

Who is a TokBox-er?

My coworkers are smart and experienced. They’ve worked for the innovative and the stodgy, from the tiny to the giant, including Mozilla, Google, Cisco, Twilio, Facebook, Telefonica, Adobe,  MobiTV, Scribd, Logitech, BlueJeans, Vodafone and more. Because of their experiences, I’m the real winner – TokBox is better, and I get to learn from all of them!

The culture is a good fit for me – yoga every Tuesday, occasional tea with the support engineers on the building deck, delicious catered lunch, weekly 1-on-1s with my boss. People try to have some fun, and have a sense of humor. I am thankful to be working here!

What, exactly, do yah do here?

What unifies my work is helping solve the problem of our users, who are mostly developers. The product team focuses a lot on trying to improve developer experience. I want them to have an easier time understanding what problems we can solve for them, and I want to solve their problems by using the OpenTok platform and our tools.  To accomplish this, I do full stack web development and solve product and growth problems. I use technology and tools I knew before (good old fashioned vanilla JavaScript, React, Node, jQuery, HTML, CSS, Jade, Stylus, Git/GitHub, WordPress). I’m adding new ones to my arsenal (DocPad, Jenkins, ReviewNinja, Docker, Elasticsearch, Kibana and more). I use tools like Google Analytics, HubSpot, AdSense, Tag Manager, and more. I lead user research sessions, and more.

I work closely with our awesome designers, PMs, marketing team, and more. I build web pages for new products and make improvements to the website and docs. I reduced the download time of our homepage by 40% by optimizing our assets and working with our DevOps team to tweak our CDN configurations.

We spend a lot of time improving our developer resources, and I get to play a big role here. We’re making our docs more usable for our developers by doing things like rearranging what resources live where, changing the information hierarchy of the site, redoing our homepage, creating an easier to use “Hello, world!”, and more. I lead some session on user research to help gather user feedback, which I used to identify issues and make recommendations on solving them – changes ongoing 🙂

I also work on special projects, e.g. building features on the React app where users manage their account, and help support growth initiatives for the product and marketing teams.

Product Is Where It’s At

Its great being on the product team. I like understanding and influencing what problem we’re trying to solve, what we’re building to solve it, and who we’re building it for as much as how we’re building it. On the product team, I get to learn about how to make a roadmap, prioritize features, develop and tweak process, see how teams work together across the organization, how designers think, how to gather feedback from user, how to incorporate feedback into the product and the product roadmap, how to strategize in relation to competitors, and how tradeoffs are evaluated and decisions are made. I’m very passionate about product and will become a product manager.

I’m wearing a ton of hats and it’s a good fit for me! I look forward to writing more about it soon.

We’re hiring for all sorts of positions! Check our openings out here 🙂

New Developments in JavaScript- Approval of ECMAScript2015, Announcement of WebAssembly

Times are exciting in internet land! ECMAScript2015 (aka ES6) has been approved, so the final specs are available for anyone to peruse. Read more about new features in a Treehouse blog post here or start fiddling around in your browser with some examples here or here.

Brendan Eich announced WebAssembly, and Axel Rauschmayer has a very readable blog post explaining it as well. In summary, the major browser players are all on board to help make a subset of JavaScript that compiles more quickly. This will be useful when performance is critical. Another bonus is JavaScript will load more quickly. Further, WebAssembly will make it easier to compile other languages for use in the web.

SQL vs NoSQL Databases – Part 2: Practice

This is part two of a two part series about databases. The first post focuses on theory, and this post focuses on the practical decision of which database to choose.

MongoDB, Redis, Cassandra, and CouchDB are some examples of popular NoSQL databases. There are a variety of types of NoSQL databases, based on either key-value pairs, documents, graphs, or columns (find out more here). MongoDB, a key-value store, has been extremely popular given how easy it is to set up and use. It comes with great flexibility, as schemas are dynamic (can be changed on the fly). If your data isn’t heavily interrelated, it’s a great choice.

Choosing MongoDB optimizes for developer time in part because of its flexibility. Setting up a MongoDB database is quick and easy. Further, your schema can be changed on the fly. As you store arbitrary objects in them, these objects can have completely different kinds of content in the fields; you don’t need to honor any schema. For this reason, it’s a great choice for projects where the schema is not well defined or could change. If you change your code, your data will go into your database with its new schema.

Further, this means you can change what your database is doing and keep your service running. Avoiding downtime is a big plus. The database won’t reject data of an unexpected type (a relational database most likely would). With smaller data sets, non-relational data is usually not a problem. Further, NoSQL is much easier to scale across many servers, and is cheaper. If all you need is simple persistent data, a NoSQL database will work well.

My group chose to use MongoDB for Glint, a forum for finding and getting feedback on project ideas. We wanted to optimize for developer time. Our needs were to track who contributed the idea, and the number of votes, so key-value pairs worked well. Upon scaling, we would consider transferring to a well indexed MySQL database to quickly see, for example, overall number of votes for a given user.

SQL has been around for years. It is battle tested at enormous scale. For a simple relational solution, SQLite exists as well. SQL databases offer powerfully interconnected data, meaning you can access and use the complex relationships within data. SQL is ACID compliant, which is a big deal. Further, well indexed data on well designed MySQL databases are performant.

Downsides to using a MySQL database include the database must be offline to easily restructure the tables. This means your service is unavailable during that time. More data generally means a bigger server. It requires some time thinking about data before using it- including the types of data you’re storing, and the important relationships between your data. It takes more time to set up for these reasons. SQL databases are less flexible – all columns have the same type of data and are the same size, defined ahead of time. The columns can’t be changed with ease to hold more characters. A new column can’t just be added to your table. Lastly, it is more expensive to maintain (you might need a dedicated Database Administrator for large datasets).

Appendix – A few useful database concepts:

CAP Theorem: http://en.wikipedia.org/wiki/CAP_theorem
Normalized vs Unnormalized Data: http://en.wikipedia.org/wiki/Database_normalization