On web startups, technology, music and growth
Wie nood heeft aan bijles voor wiskunde, fysica of talen kan steeds terecht bij Integrip Coaching, een populair bijleskantoor dat vooral actief is in en rond Kortrijk. Uit persoonlijke ervaring weet ik dat zij erg weten waarmee ze bezig zijn!
Integrip specialiseert niet enkel in ‘pure’ bijles, maar gaat ook prat op sterke ondersteuning van de student, met aandacht voor zaken als studiemethode, goed plannen, tips bij het voorbereiden van ingangsexamens (zoals het ingangsexamen geneeskunde) en meer.
Soms is er niet meer nodig dan een extra stimulans tot concentratie – dan kan begeleid studeren effectief zijn.
Klik hier voor meer informatie over het aanbod van Integrip Coaching.
So here’s the thing: I consider myself pretty decent at ‘business networking’. The reasons for that are that I am not too intimidated when striking up a conversation with a total stranger, but even more – I like to think – that I try to listen attentively, and am genuinely interested in what people do and have to say. Every encounter is an opportunity to learn after all. Dale Carnegie would be proud.
So, generally I have always liked attending or speaking at various business or networking events. And while I am not much of a ‘smooth talking sales guy’ or even ‘business person’ overall, often enough I do end up with valuable conversations where we end up discovering next steps that can bring both of us clear value – an agreement to try a demo and see if there’s a fit, a promise to dedicate a blog post to each other’s product, etc.
So we’ll end up with a heartfelt hand shake, a quick exchange of business cards or a linkedIn request, and a genuine ‘looking forward, talk soon’ for after the event.
The problem is what comes next.
Because, you see, beyond first encounters, I am not the most ‘socially organised’ person, to put it mildly. I barely tolerate entering data in a CRM, have a virtually non-existent memory for names, and typically end up with is a big pile of crumpled business cards of which some are connected to a really great conversation that I need to follow up on, and the majority is because exchanging them was a politeness. But which was which, again?
And besides, I’m tired and my head is still spinning from the event – by the time I can bring myself to the ‘follow-up’ part, the nice personal details of the conversation are long forgotten, and the CRM looks like a drag – I got a full inbox waiting thank you very much.
So here is my fix that I have tried with success on various events I attended.
For those great conversations in which there is clearly value to pursue more conversation, I fire off a quick email on the spot. So either I straight up refuse their business card, pull out the Gmail app and say ‘never mind that, just give me your email’, or I accept the business card and before continuing to the next ‘mingle’ I make sure to take the email address from it and fire off that e-mail.
I have found this to work pretty neatly for me, not just for the reasons above, but also because:
Still, the system has its drawbacks: I always have to type the full message (even if it’s often just a subject saying ‘Great to meet you at [event], let’s talk [topic of continued value] soon!’ even if most parts of it – but not all, I’m not a robot! – are repeated.
So, on to a solution, or rather a concept of a solution: together with a friend of mine we’re created a little app for that to make this process even more seamless. We christened it ByeTalkSoon, and it’s very much ‘minimal viable product’ (only works with gmail for example), but still, I like it a lot!
So, event networking app ByeTalkSoon.com is officially online now, and I’m very curious to see if this a ‘problem’ worth solving or if I’m the only one that has it!
TeamView is a new cloud app that aims to be the ‘productivity app to end all – well, most – productivity apps’. The idea was born from seeing again and again and again how a company faces the ‘ok, we should organize this better’ question on parts of their process, and they are then faced with these options:
Something’s missing here. So many things need organising right from the start, while very few of those should require a choice between a mess and an investment.
As a developer, there is always a third option, because you see crystal-clear what the solution to the ‘we should organize this’ question is:
But to stand a chance at being adopted, a relational database needs a better interface than PhpMyAdmin, which – I speak from experience – has way too many scary ‘drop’ buttons that should almost never be touched.
Enter TeamView, which is ‘just a relational database’, except it has a user interface worth the name, doesn’t require a degree in relational queries to set up, and is instantly accessible as soon as it’s set up. Throwing an ‘app’ together to manage your meeting rooms or who is using which company computer should be easy.
I have a lot more to say on the subject, and TeamView is very much still in the ‘idea phase’, with me frantically building a bit towards ‘MVC’ when I have an hour to spare here and there.
But this post is mainly just to prove a point about brand name uniqueness and google. Go to TeamView.
This is just a sketch of a draft of an idea, and it may turn out only to apply to myself, not others or something.
Many books have been – and will be – written about productivity, and similarly so about happiness. These are some thoughts I had the other day, reflecting on the things I do and the order I do them in for my little mini startup TadaBon. How do we prioritize the tasks in a specific project, or throughout our daily life, in order to be productive, get things done, and hopefully not go to crazy or depressed in the process?
BUT, I think there’s an interesting little framework to think in when talking about happiness and productivity, called the ‘FLUID’ model, an acronym for Fun, Length, Urgency, Importance and Difficulty. It aims to be simple enough to easily explain our behaviour and motivations when working on projects, but also complex enough to explain a wide range of things.
And like most theories, the first goal of them is to be consistent, then to explain existing stuff, and lastly to help formulate answers to problems. So I guess goal #1 is this: given that you may interpret ‘fun’ to be extremely broad (like, the entire upper half of Maslow’s famous pyramid), can every single task or aspect of a startup or general project fit in this framework?
Obviously this is meant to be tongue-in-cheek, not as a serious ‘model’. I just happen to like models (in at least two senses of the word, come to think of it :)). This post is also just about ‘introducing’ and exploring the concept, since writing helps me organise my thoughts.
Or maybe it’s just an excuse to see how far I can get with making 5D charts.
From the solutions I’ve tried, HighCharts’ 3D scatter plot so far seems the quickest and handiest way to do this, producing something like this:
(the colors should actually just range from red over yellow to green, indicating the difficulty dimension, but I didn’t get that to work yet while maintaining the ‘3d-ish’ look with the shadows.)
Both the famous ‘Getting Things Done’ method and our own instincts suggest to prioritize tasks by the following 2 dimensions: importance and length (time the task will take). Do the important and quick stuff first, then the important stuff that takes longer, then the rest.
(disclaimer: I didn’t read the book, just read – about – it, and I know I am grossly oversimplifying, so I may be totally off here, sorry for insulting any GTD fans)
… And that’s how we all prioritize our inbox, right? Unfortunately, life gets more complicated than that.
I SHOULD be doing the important and urgent stuff (say, finding more users or replying to their support inquiries), but instead I am here writing a blog post that contains scatter plots and does not remotely contribute to my project. Not sure where my point is, except that like so many things, it scores low on everything but the F part.
I also just realized that ‘difficulty’ is definitely related to fun, so maybe I should leave it out. But then I don’t have my nice acronym. Also, I like (some) things that are difficult, like trying to create a 5D chart.
Ok whatever, just publishing this now just to make sure I don’t forget about it (which I tend to do with ‘draft’ posts), but obviously this is just a draft of half a thought.
Some more vague thoughts surrounding this thing and how it might relate to startups:
To close this post I’ll just leave this fragment from Scrubs which is highly helpful in promoting my conceptual model:
I should get back to doing real work.
Tadabon is a platform that enables small/medium merchants to offer printable gift vouchers online. It’s a spare time project intended as a learning experience, and I’m trying to document it as I go (with some delay though), however good/bad it turns out. Timeline of this post: nov-dec 2013. Previous part.
Allright, so I got a plan: build an online gift voucher site. Time to build it! Luckily I have lots of very relevant code lying around from my previous project, so I decide to make the most of that. Since this is about growing a site as much as it is about simply creating it, The goal is to get a ‘minimum viable product’ out there as fast as possible, and iterate from there based on what I learn from talking to my target audience.
I generally suck pretty terribly at design (both conceiving it and writing decent CSS), so I take a heavy short cut and buy this nice bootstrap-based template which has an admin backend, a corporate frontend and an e-commerce site for 10 bucks. It includes even a blog layout! Exactly what I need for my project, perfect.
For the code framework, I completely reuse the small MVC one I self-built and created and evolved over the years, including for MyShoppingTab and Barlisto. Its template engine is (a by now heavily modified version of) QuickSkin, and the framework by now has all the usual stuff with straightforward URL routing, database wrappers, controller class inheritance so that rights and stuff like that is easily shared, easy methods for storing and retrieving from a cache, utility methods for manipulating arrays, generating random strings, doing cURL requests, a complete debug log of queries and actions to view on each page what is going on, etc etc.
I’m sure it’s messier and hairier than many ‘prefab’ MVC networks, but I know my way around it really, really well. Another time saver.
Apart from the PHP code framework, other ‘app-level’ aspects already ready and easy to port were:
… All in all, that’s a lot of stuff if you add it up! None of this is overly hard or complex, but if you’d have to write it from scratch I imagine it adds up.
Many of these things are necessary, and others are a definite plus for even a moderately complex web app, and typically come out of the box many PHP frameworks (things like Zend or CodeIgniter or RubyOnRails), but again, the great advantage is that I know my way around them so well so customizing for my first version gift voucher platform can go relatively fast.
What has to be in there is pretty straightforward: something that allows a merchant to sell vouchers online, and to dynamically add and manage the elements needed for such a page. Actually, as seen above, that by itself already has quite a lot of elements just to function and be secure and usable.
A lot of fun and piece of mind is to scratch out what is not gonna be included, even though MyShoppingTab already has it, and it’s pretty natural to think how it would add value and growth potential. In this phase ‘NO, NOT ESSENTIAL’ is a great way for peace of mind, and the answer to 90% of feature ideas:
Now, just to be clear, by the time I’m writing this pretty much all of these features are in TadaBon (and others on their way), but none of them were necessary for the first version to provide its core value: a way to sell a printable gift voucher online. If I cannot get that part to work and convince somebody it’s useful, who cares about Facebook login.
Writing the first version working off this base actually happened in parallel with gathering initial user feedback (as a nice change from just coding). Things like coming up with a project name and doing the other ‘online marketing groundwork’ like building a project site and setting up the right online marketing tools, but I think that’s worthy of a blog post of its own.
The same theme as above will continue for the presentation/marketing though: the most important part is getting something out there that works, so if it’s ugly and poorly written, I can live with that. As with the app functionality, the goal is not to impress, the goal is to launch.
After all, real artists ship.
I gave a brief presentation at the Growth Hacking Belgium (if you’re interested in the whole ‘growth hacking’ thingie at all, join them!) Meetup in Ghent on the topic of ‘A/B testing’. These are the slides:
The sources of the examples used are as follows:
Tadabon is a platform that enables small/medium merchants to offer printable gift vouchers online. It’s a spare time project intended as a learning experience, and I’m trying to document it as I go (with some delay though), however it turns out to go.
Timing of events in this post: Summer-fall 2013.
TadaBon as a web project was born more out of these 4 things, all happening during or after the summer of 2013:
MyShoppingTab was/is a platform that allows small merchants to create a web shop that functions entirely (including payment, which is quite unique) in a tab of their Facebook page, with no technical knowledge required, and lots of customization/personalisation options, both in the design and the wording.
It grew to be a rather advanced and full-featured app and I’m quite proud of that, but strategically it also had several drawbacks. The biggest ones are the following, and online printable gift vouchers fixes some of them in a straightforward matter:
Tadabon fix: positioning it as a central platform, allows me to help driving traffic to the site in general, thus not leaving it entirely in the vendor’s hands.Tadabon fix: still center around ‘shops’ for merchants, but also market it ourselves as a portal.
Tadabon fix: no inventory of physical products needs to be there, and it doesn’t have to be kept up-to-date with products in stock. What’s more, no physical shipping is needed, another hassle removed.
Tadabon fix: it will be a separate web site, with Facebook perhaps used as a possible sharing / growing platform but not the main focus.
Some more strategic/product decisions made early on:
Ok that’s about it for what lead up to Tadabon. Next edition will be about building the actual product and gathering initial feedback to get a sense of, well, the sense of it all.
Ok, so you own a web site with users. Here’s what you typically do with your login form, where you ask e-mail (or perhaps nickname) and password.
You do some kind of query in your database if there is a user with that email + password combo, and if you found something, you log that user in. So something like:
SELECT * FROM users WHERE email=:email AND passwordhash=:passwordhash
So far so good, and bonus points for you if indeed you do not store passwords in plaintext and even more if you use a salt with that hash. Most companies get at least the no-plaintext part right these days I think. Good.
BUT, what if that query returns nothing? Here is what 99% of web sites do, including big ones like Twitter:
What GOOD sites do when no user/pass combination is found in the database, is a second query, to determine whether it was just the password that was incorrect, or perhaps the email does not exist in the database. As so often, Facebook gets this right because they are pretty good with the whole UI thingie:
This does not impose that much of an extra load on your server because the extra work is only done when somebody gives a wrong email/pass combo, so this would not double your queries on your user database or anything.
That’s all, thank you for listening. I’d love it if you share this post if you have been annoyed by this as well, or comment on it if you think I’m completely wrong in having this as one of my (many) pet peeves.
P.S.: I know there are arguments that can be made against revealing that a certain email address corresponds to a user. For example, perhaps it potentially gives people with malicious intents a (cumbersome) way to tell that an email address exists or that a given person is on a site.
And perhaps Facebook can get away with this because everybody and
there their mother is on it, but perhaps you feel your Defense NASA Banking site cannot. Still, I don’t think most sites thought this far, and just go with the lazy route because everybody else does it so they get away with it. And at the very least, you have measures to prevent automated non-humans from submitting your login form I’m sure.
UPDATE: many people pointed out to me that the afterthought I so casually put inside a post scriptum is quite an important one. Maybe, to not give any information to hackers, here is an approach that is a bit more secure. Store the user’s email address in a cookie (even if you don’t have a ‘remember me’ cookie login, in which case all of this is obsolete of course), and if the email address he tried to log in with matches that cookie, then show him that the address exists but the password is wrong.