Monday was a horrific day in Boston and its been an uneasy day after. I don’t have anything to add to the discourse but I would like to urge you to join us, along with the technology community in supporting the victims.
TUGG has setup a fundraise.com page here – https://www.fundraise.com/technology-supports-victims-of-boston-marathon-bombing and over $100,000 has already been raised.
In 2009, an engineer using the pseudonym Satoshi Nakamoto introduced a new digital, open source, currency to the world called “Bitcoin”. Since then, the buzz, excitement, and adoption of bitcoins has grown at a phenomenal rate, with the total value of bitcoins in circulation hitting $1 billion as of April 2013. Talk of a bubble has coincided with the buzz, but both have also served to highlight the tremendous potential in the Bitcoin ecosystem.
Paraphrasing from Wikipedia:
Bitcoin is a decentralized digital currency based on an open-source, peer-to-peer internet protocol. […] Bitcoins can be exchanged through a computer or smartphone locally or internationally without an intermediate financial institution. […]
Bitcoin is not managed like typical currencies: it has no central bank or central organization. Instead, it relies on an Internet-based peer-to-peer network. The money supply is automated and given to servers or “bitcoin miners” that confirm bitcoin transactions as they add them to a decentralized and archived transaction log approximately every 10 minutes.
I’m going to butcher any explanation I try to provide but Quora has several good writeups on what Bitcoins are and how they work. A reasonable analogy though, is think about “Bitcoins” as a type of precious metal that has no intrinsic value but is able to store value, transfer value between parties, and be mined to find new pieces.
The key takeaways about how Bitcoins work are:
There are dozens if not hundreds of startups playing in the Bitcoin space and several “large” companies have also started adopting Bitcoins as an alternative form of payment. Several high profile investors including YCombinator and Union Square Ventures have also made significant Bitcoin related invetments, signalling that savvy investors believe a potential market exists. Personally, I’m excited about companies attacking the following:
Hassle free, instant, and international money transfer. Paypal was supposed to allow us to do this, but even in 2013 its difficult and expensive to transfer people money – let alone internationally. If someone can address the current concerns of fraud and money laundering using Bitcoin they’ll have an instant winner on their hands.
Catapult in legalized online gambling. In the last few years, there’s been an ongoing discussion about if America should legalize online gambling and if so, how it should be done. Because of the decentralized, anonymous nature of Bitcoin, it’s conceivable that the emergence of a large enough Bitcoin powered gambling market would force the US government to legalize online gambling in order to get access to the additional tax revenues. This would obviously be a boon for struggling social game companies like Zynga, but also provide an enormous opportunity for new startups.
Provide a viable alternative to credit cards. Recently, there’s been a lot of action in the payments space including innovative companies like Square and Roam which are aiming to alter how consumers pay at the point of sale. Unfortunately, almost all of these new payment solutions still rely on existing credit card infrastructure to complete the payment which leaves them at the whim of interchange fees. Boston based LevelUp is tackling this issue but at the end of the day they’re still getting hit by the fees somewhere. An innovative Bitcoin company which provides a viable alternative to this existing credit card infrastructure would open the door to radical innovation in the payments space by eliminating hard interchange fees.
There’s a huge amount of opportunity in the Bitcoin space and the ecosystem is just starting to build out. With the Bitcoin boom of 2012 already inked on the Wikipedia entry, the next few months are going to be a critical time for the nascent currency. The single largest to Bitcoin is ultimately going to be regulation from sovereign governments. The US Department of Treasury has already issued several statements regarding Bitcoin and its clear the government isn’t happy with the situation as it stands now.
Regardless of what regulation is passed, Bitcoins are technologically different from previous virtual currency and the ecosystem has already demonstrated its resilience and innovation.
One of the hardest things to do when building a software product is effectively communicating your ideas to your development team. In addition, these issues are usually magnified when you’re early on in your product process. Generally, communication issues between stakeholders and developers fall into “macro details”. “expected behavior”, or “user interface concerns”.
Despite being an oxymoron, “macro details” captures the types of errors that occur at the architecture level. For example, imagine you were building a calendaring system for intramural sports teams where each team manages their games for the season using the calendar. A “macro detail” would be that each “team” owns a single “calendar”, a potential error then would be the development team coming back with a solution where every “player” on a “team” owns a “calendar”. Following from that, the “expected behaviors” of the system would capture issues like “what happens if two teams try to schedule a game for the same day?” or “can a player be on more than one team?”. A defect then would be that the stakeholders expected the system to not allow multiple games on the same day but the system allowed it. Finally, “user interface” concerns would typically encompass how the various components of the application are organized and what the different screens are.
Great, so how do you avoid these problems? What follows below is a loose framework for mitigating these issues, it certainly isn’t original but rather a synthesis of techniques that I’ve seen help power effective communication.
For a totally new product, getting started is often the hardest part. Usually, the entrepreneur or executive who is building the product has been frantically planning, talking about, and “living” the product for sometime before the project actually kicks off. The result of this, is that the stakeholder intimately knows the ins and outs of the project but the rest of the team won’t necessarily be aligned with the primary stakeholder. Because of this, starting by writing a 1 – 2 sentence “10,000 ft. view” is usually a great first step. Using the sports calendering example from above, you might end up with:
I want to build a calendaring application to allow intramural (think old man kickball) sports teams to collaboratively plan their games for the season.
With the “big idea” down on paper, the next step is to start defining the primary objects in the system and how they are all related. At this stage, other people normally develop “user personas”, which describe typical users of the system, and then elaborate on how each persona will use the system. In my experience, this approach is effective but inexperienced stakeholders tend to get caught up in the details and ultimately have a difficult time reaching the right level of abstraction. Looking at the calendaring app, some of the objects you’d end up listing would include:
Anyone that is familiar with Unified Modeling Language will notice the format is similar to how UML uses nouns and verbs but its a bit different. I’ve always had better luck using natural language to write out the relationships between entities and then converting that into an entity relationship model and then RDMS tables.
Once the primary entities are defined, the next step is to write out the business logic to minimize the confusion around how the system should work. There are formal structures for this as well, including behavior driven development, but in my experience its easier to kickstart the conversation with natural language specifications and then introduce BDD later in the development cycle. Anyway, running with the example you’d end up writing out something like:
Like with the entity relationships, I usually start with natural language and keep the definition of “business logic” pretty loose so that I can capture as much information with the stakeholder as possible and then formalize from there.
Finally, the last piece is usually communicating what the UI of the application should be. Depending on the makeup of the team, the amount of input that business stakeholders have in this respect might be minimal. However, if there isn’t a dedicated UI/UX resource available UI mockups will definitely be a valuable asset in helping communicate the vision of the application.
There’s several tools for developing UI mockups including Balsamiq, OmniGraffle and Mockflow. Generally, any tool you’re comfortable with will work fine but the key concern should be not “lowering” the designs too far to allow people to concentrate on the ideas, not the specific implementation. I’ve always been partial to Balsamiq since its attractively priced, easy to use, and the final mockups are more like sketches than a finished design.
Anyway, sticking with the calendaring project you might end up making a screen that looks like this:
Like everything else, the definition of UI mockups are generally flexible. Some people like to “lower” pretty fair to high fidelity designs and other people like to leave them at “pen and paper” type sketches. At the end of the day, it’ll be a project by project decision.
Well thats a crash course, with examples, of how I generally work with key stakeholders to sketch out projects. Ultimately, figuring out the best way to communicate your vision to your engineering team is going to be a personal decision. You’ll probably end up having to mix together several techniques that take advantage of the skills on your team and match the requirements of your project.
Being a services business, we’ve always been lured by the forbidden fruit of developing a SaaS product, selling it to a bunch of users, and then sitting back and watching the revenue pour in every month. Over the last few years, we’ve been approached a couple of times by people looking to have us serve as the engineering team of a company in exchange for equity which would eventually begin generating revenue. Despite this situation being relatively common, there are relatively few guidelines on how to approach receiving equity in exchange for work as a services company. With that in mind, here are some guidelines we use in these situations. Also, these suggestions are probably also equally applicable if you’re a services company looking to develop a product in house.
An issue that we’ve repeatedly noticed is that equity or internal projects are often treated as “second class” citizens within service companies. Since they aren’t billable, companies end up doing things like leaving them off the planning schedule, pushing the work off until Fridays, or only assigning interns to the project.
One strategy to help combat these issues is to on-board the project like you would any billable project. Depending on your process, this might mean doing things like creating a Basecamp project, adding the project to your time tracking software, and holding a “kickoff meeting”. Whatever your process may be, the takeaway is to treat the non-billable project like a normal one throughout your organization.
Budgets are important for any project but they’re especially important when equity is involved or it’s an internal project. When dealing with a non-billable project, you’ll want to avoid the “equity guilt” where you’re guilted into “doing just a little more” since you own a measurable % of the company as well as eventually be able to calculate an ROI for your investment. A proper budget will help you do both since you’ll be able to know when you’ve contributed your fair share and hopefully one day calculate your ROI against the budget.
Developing a budget in these situations is relatively easy, just take how you’d normally bill and decide on a number for the version one of your buildout. If you bill hourly, pick a number of hours, if you bill by the week then pick a number of weeks. Since the project is already set up as a “first class” project you should be able to just add a budget against it.
One of the problems that arises in equity deals and internal project is that there isn’t really a client and subsequently there often isn’t a single person responsible for making key decisions. Having a single person that ultimately “owns” the project will mitigate “design by committee” issues and also help keep the momentum of the project going.
Fair warning though, “owning” a failed project carries a heavy emotional and psychological toll so as an executive you’ll have to be ready to support an employee that accepts this responsibility.
Clearly spelling out who is responsible for what is important when a services company is being brought in for equity. Detailing responsibilities will help you avoid a situation where your team started off as the marketing team but then ended up fielding support issues and ultimately resenting the project.
Knowing what you want to track and how you’ll measure success is important when money isn’t being exchanged because it helps keep everyone accountable and prevents the project from slowly stagnating. Having a good handle on your KPIs also helps motivate the team if things are going well and they’ll ultimately be a primary factor in deciding if you should continue the project.
Unfortunately, one of the hardest aspects of any project is knowing when to quit. This decision is usually harder in equity only or internal projects since there’s no pressure of burning capital and there won’t be the finality of the money running out. Despite this, knowing when to pull the plug will help you facilitate an orderly shutdown of the project and also give everyone involved the chance to debrief.
So should you do an equity only project? Well it depends. Given the the reality of startups, chances are you’ll not going to enjoy an eight figure exit and retire a millionaire. But chances are, if your team gets involved with an interesting project they’ll get a chance to learn a lot, experiment outside their comfort zone, and maybe even leverage the project into new business. So my answer would be a “maybe” depending on where your business is and what sorts of opportunities you’re being presented with.
One of the most interesting companies in the ad:tech space right now is AppNexus. What AppNexus provides is basically the infrastructure necessary to build and run an internet display advertising business. In addition, they also provide a REST API to access the majority of the platform’s capabilities. This post will walk through how to use the AppNexus platform to setup audience retargeting.
With the rise of “real time bidding” in the display advertising space, it’s now possible for advertising choices to be made in real time at the individual user level. Basically, what that translates to is that as a web user every time you see a display ad an algorithm is transparently deciding how much to pay to serve you that ad. Using this technology then, its possible to “retarget” visitors that had been on your site as they see ads across the Internet. So with AppNexus, you’d basically be using their platform to “tag” your users and then leverage their RTB connections to show those users ads as they browse the internet.
Using the AppNexus platform to set up retargeting is relatively easy. First, you’ll need to leverage the “Get UID” call to retrieve the AppNexus id for your user. The URL is structured like:
http://ib.adnxs.com/getuid?http://www.yourdomain.com/getId?id=%24UID
The /getuid service will generate a 301 redirect to the URL you specify and replace the $UID placeholder with the user’s Appnexus id. If you’re planning to process users with a batch process, you’d want to store the id that gets returned from AppNexus so that you can target those users.
The next step is adding users to AppNexus segments which will allow you to target them across RTB exchanges. There are two ways to achieve this, you can either add users to segments in real time using an AJAX call or you can add them in bulk by uploading a file to AppNexus. Adding users in real time is straightforward, the AJAX endpoint is:
http://ib.adnxs.com/seg?member=USER_ID&add=SEGMENT_ID
Using the batch process is a bit more involved, you’ll have to generate a file with AppNexus ids and segment ids and then use the batch service to process the file.
Plugging into the AppNexus infrastructure like this opens up a lot potential applications and use cases. Some potential use cases are:
Anyway, if you’re interested in building solutions on the AppNexus API we’d love to work with you so drop us a line.