Skip to content →

Category: Uncategorized

Crowd funding, Drones, 3D Printing and the Digital Economy

As software is eating our world; how we buy, build and consume products is changing. This is a story about the Digital Economy and my experience dabbling in it.

Crowd funding

It started about a year ago when I backed a new project on KickStarter. They had a nice idea for a Drone that could collapse down and fit in your pocket (large pocket). They had a slick video and got some good media attention. The price looked good and I had had a pretty good experience with a few other KickStarter projects so thought I would go for it.

image

Over the course of a year we would get regular updates, pictures from factories, drones being assembled and tested. Everything looked good albeit the project was taking a lot longer than was expected. Finally at the beginning of this year I got an email confirming shipment. To say I was excited was an understatement. Then it went quiet. No delivery, no updates, nothing. About a month later I checked the KickSarter page to see if there were any comments:

image 

It did not take long to find out that something had gone very wrong with the campaign. Lots of people had received the wrong pledge, other people had not received anything and worst of all nobody could get their drone to fly Sad smile.

Luckily a couple of days later a parcel turned up and my drone had arrived. The box looked good and I opened it up to find everything there. I followed the instructions, charged it all up and went outside for my maiden voyage. But just as many other had found out, this drone aint going to fly in a hurry.

MaidenFlight

I later got a message from AirDroids; the gang behind the campaign who claimed the they ran out of money and that they had to take personal loans just to get the campaign to the end. Not sure I entirely believe it, however I am pretty sure that their intentions had been genuine, just their execution was poor. 

Conclusion

Making products is difficult, product development, manufacturing, logistics, marketing are all hard. Just because a KickStarter campaign gets noticed does not mean that its going  to be a success. Especially when it comes to hardware.

Social Support

Back onto the KickStart page I found a like to Facebook group that had been set up by people who had received the drone and knew what they were doing.  https://www.facebook.com/groups/661830653926054/?ref=browser

An amazing guy called Rolf van Vliet who obviously knows what he is doing put together a fully comprehensive guide to the pocket drone, including all the modification that you have to make to get it to fly.

Another couple of hours of calibration, modifications and playing about and I finally managed to get the little drone into the air!!!!  But still flying behaviour was poor. It would fly for about 20-30 seconds and then crash, slowly destroying the airframe.

Conclusion

People are amazing, The number of people that came together on Facebook and help each other out is fantastic and a big thanks to the time that Rolf van Vliet spent putting together the support guide.

Just because somebody can build it does not mean its any good. The design of the pocket drone is very poor, breaking on crashes and unable to maintain calibration for flying. These guys were not engineers!!!

Social design & 3D Printing

With all my crashes the drone was not fairing well. Its landing gear had taken a battering and was destroyed. But this is the Digital Economy, thats not going to stop me!!! Somebody had designed a set of new legs and uploaded the designs to Facebook for other to download and get printed up using a 3D printer.

PocketDroneleg_preview_featured

http://www.thingiverse.com/thing:828851

Not to be beaten I used a service called 3D Hubs who are a broker for people with 3D printers. You upload your design and they will calculate the printing cost, suggest people that can print up your component in your area and manage the payment and transaction. Within a couple of hours I had a local guy here in Dublin printing me a new set of legs for the Drone.

2015-05-27 20.10.562015-05-27 20.15.45

So back out with the drone and a few more test flights later I am back to 3 broken legs.

Conclusion

Again, the fact that people have taken the time to model up these legs and distributed them freely is amazing, but just because a person can model something in 3D does not make them an engineer and these legs did not last 1 crash.

Shipping from China

Rather than waste any more time with a poor design I chose to go with a new carbon fibre airframe that I found on Amazon.

tr-airframe

Unfortunately it never turned up!!, so now I have tried buying it from a dealer in the UK over Ebay.

Conclusion

There is so much technology wrapped up in these little drones and its amazing how many people are prepared to invest their time in building drones and helping others to have fun. But the number 1 thing I have learn is that just because you can build it does not make you an engineer. But this got me thinking, Just like the ubiquity of cheap PCs and accessible programming languages has turned programmers into the new cool maybe the next big thing will be for engineers!!!! Maybe its time that engineering will become a great profession again as the demand for decent engineers who can design proper hardware that they can now manufacture on their bench. 

Time to dust off my old engineering books!!!

Leave a Comment

Winning with Azure in the Public Sector

Really proud to win Public Sector Project of the Year with the Energy Credits Management System. An energy measures platform built on Azure Platform as a Service for SEAI. A great solution delivered for a great client. I will come back soon with some more details of the project, architecture and how we built it.

2015-05-15 09.36.41

Leave a Comment

ASP.NET vNext – CTP4, Package Managers (Notes)

Naming for ASP.NET is now 5.0

Middleware = IApplicationBuilder  *there is a lot of contention around this

Design time host now compiles the code as you write, this enabled provides better intellisense. Compiled bytecode is pulled from the design time host into IISExpress in realtime in memory. This is the metaprgramming support, there are hooks so that you can do funky stuff on compilation.

KVM is the tool that is used to manage the KRE (K Runtime Environment) on the machine.

Web.config transforms

App knows what the environment is using an Environment variable. Variable is set to production by default, Install VS sets it to Dev. Use the StartUp.cs to evaluate the Environment variable and change the system configuration.

Supporting SemVar2 as part of Nuget 3

Nuget has poor support for Content files, this is a challenge for vNext as the content files needs to be moved as part of the build process. Bower is the package manager for content files.

Leave a Comment

Lean Startup Machine – London October 2012

Over the past year I have been familiarising myself with the Lean Startup methodology and trying to adopt it in both my bootstrap evening enterprises and my IT Consultancy day job I had heard lots of great things about London Lean Startup Machine (LSM) and thought it would be a great way for me to learn from other people and challenge myself in some of the areas I am more uncomfortable (incompetent) in. The weekend is focused on customer development and the right hand side of the Business Model Canvas. Rather than the building and deliver of the solution. Its not a hackathon, but more like The Apprentice on steroids where you have to develop your own internal Lord Sugar to criticise you.

The weekend starts with a Friday night introduction session, where people can pitch an idea that they would like worked on over the weekend. My objective for the weekend was to focus on process, so I opted to be a participant rather than pitcher. Once the pitches where complete individuals had to choose which idea they want to work on and then form a team.
The idea that resonated with me the most was that pitched by Thomas Thüer, a mechanical engineer from Switzerland  who identified a problem that not everybody has the time or a schedule that allows them to attend an organised activity e.g. Football on a Saturday morning, and that there must be a solution that could help people organise more events.

I immediately felt an empathy with this problem as having 2 kids and a busy work life I very rarely have the time to attend more formal organised events, let alone organise stuff myself. However when I have the time it would be great to do stuff (Mountain Biking, Kite Surfing, Running etc) with other like minded people.

Once we created the teams we started breaking down the problem and dropping our assumptions into post-it notes onto a white board so that we could pull out our most riskiest assumptions.

Customer development is all about talking to customers and we quickly realised that finding people that “Wanted to do activities with people but could not because of their busy schedules” where going to be pretty hard to find. This lead us to a pretty early “customer segment pivot” to focus on footballers wanting to play football in the park (not unusual when you consider we where near Regents Park on a Saturday, lots of people playing Football).

In reality our problem statement was pretty poor and targeted a rather inaccessible customer segment. So, in the spirit of learning the process and not focusing on the actual product, we decided to push on through the stages of developing a product pitch and concierge MVP.

The weekend’s work was focused around the new ValidationBoard (designed & developed by Lean StartUp Machine) which we used for charting our progress.  Its a great tool for using as the backbone for you customer discovery, however we found it heard to be iterative. We found that our interviews ended up creating a significant amount of data which when sorted through provided us with enough data to validate a number of assumptions. As a result we ended up using the Validation Board more as a retrospective documentation tool.

I really liked the way that the board helped with documenting our findings and is a format that I will continue to use moving forward.

So what did I learn?

  1. I hate speaking to customers, much happier stuck behind a computer.
  2. Its not actually that hard to speak to customers
  3. I need to push myself harder to speak to customers (there is a trend here)
  4. Its much harder to focus on the problem rather than the solution than I expected
  5. Leading a Lean StartUp team requires a split personality disorder, 1 to question every assumption/opinion that is spoken, and the other to encourage and inspire the team to believe that the problem is worth solving.

Next steps for me:

I need to go back and start retrospectively applying what I have learnt to my existing projects, as I think that there is a lot of undiscovered insight to be learned. Plus I need to develop my Split Personality Disorder some more.

Advise for anybody looking to attend:

If you ever intend to start your own business just go along.
Focus on why you are there, learn the process or to win?
Pick a project that is suited to the weekend, e.g the winning teams both picked projects that had easy access to customers.

Thanks to Ryan MacCarrigan, Obi Mbanefo and Michael Hann for organising an excellent event and thanks to all of the excellent mentors who spent their weekend helping, guiding and supporting us.

For those interested here is our final presentation for KickNow a platform for crowdsourcing a football team within your local area for a improptue kick about!!

Leave a Comment

How much to charge for my webapp?

Over the past couple of months I have been compiling a list of the costs of different webapps into an Excel Spreadsheet to get some insight into what other people charge.

My conclusion is that utility based applications e.g Basecamp average around $3500 per year for an Enterprise account. Where as Revenue Driving applications e.g. Seomoz, average around $8000 per year for an Enterprise account

My conclusion from this analysis is that if I am going to build a Muse I should certainly target revenue drivers rather than utility based apps.

I have posted the spreadsheet on Google docs, so please have a look and add any that you think would be informative.

Leave a Comment

The 500 checklist

  • Product solves a problem for a specific target customer
  • Capital-efficient business – operational @ < $1M funding
  • Primarily internet-based distribution – search, social, mobile, location
  • Simple revenue models – transactions, subscriptions or affiliate
  • Functional prototype before investment (or previous success)
  • Small but measurable usage – some customers, early revenue
  • Small but cross-functional team – engineering, design/UX, marketing
How does your Lean Startup stack up?
Leave a Comment

Designers Vs Developers

I have a great appreciation for design and understand its importance in the online & offline world, however on the last few projects I have worked on I have found a great deal of friction between the designers and developers. This has often been born from the fact that the designers work in Photoshop, and have therefore had no real restrictions to what they can deliver, yet the developers have had to implement whatever came through from design irrespective of how hard, or even if it was possible.

The success of Twitter’s Bootstrap and even the iPhone can be awarded to the specific UI guidlines set out by Apple, and it proves that people can build incredible stuff quickly and cost efficiently when they dont have to worry about design.

So, to that end I asked our front end developer to document our UI framework ala Bootsrap style, so that we could move forward from pixel pushing and build from using UI building blocks. Their response was this the Tesco Entertainment UI style guide which I think is a fantastic result, and means that our developers can deliver more functionality faster and cheaper. Well done guys. Credits to Steve Uprichard & Gareth Slinn

Leave a Comment

The Life of a Story

A colleague of mine Derrick Malone put together some instructions for how to manage User Stories during our development cycles. This was published on our internal wiki, but I thought that it was worth publishing to the wider audience due to its excellent, concise delivery. So with Derrick’s permission here it is:

Discovery

  • Business rep gathers ideas from around the business (Tesco in this case) and raises with BA
  • BA captures ideas in Pivotal Tracker Icebox, providing what info he can and also raising obvious questions in ‘Descriptions’
  • Tasks can be used here to describe next steps to be undertaken to aid understanding
  • BA and business work together to understand who the story benefits, what is to be developed and why a postive outcome is to be expected.

Planning

  • When it is better understood the initial story is split into sensibly sized stories, each of which can be released independently to deliver value.
  • The stories are ordered sensibly by the BA and prioritised by the business to deliver most value (and learning) first
  • All dependencies (eg designs, platform work, unanswered questions) are identified and captured in the user stories
  • Stories are presented to the development team for their input and estimation.
  • story is estimated if it is suffiently understood by the dev team
  • There are four acceptable estimates:
    0 – no dev work required
    1 – a small amount of dev work required
    2 – a medium amount of dev work required
    3 – a large amount of dev work required
  • story should take no longer than a week to complete. If developers think it it exceeds a week the story should be broken up into smaller stories that each delivery value.
  • When fully understood and estimated a story can be prioritised into the Pivotal Tracker Backlog

Delivery

  • When available a developer picks up the highest priority story available (the story nearest the top of the Current column).
  • The developer should review the acceptance criteria, hit the Start button in Pivotal Tracker and discuss the story with the BA and a tester.
  • In the Tasks field the developer should document the steps he will pursue to meet the acceptance criteria and deliver the user story.
  • When the developer has completed the work necessary to satisfy the acceptance crieria he demonstrates the feature to both a tester and the BA.
  • If all agree that the story can now be passed on to a tester the developer hits Finish on the story and moves on to a new story.
  • A tester takes the highest priority story marked with ‘Deliver’.
  • The tester hits the Deliver button to own the story.
  • When a tester is satisfied that the story is done he should demo to the Business and/or BA and, if they agree, he can hit ‘Accept’
  • If a tester finds problems with the story meeting the acceptance critera – or other problems with the story implemenation – he raises issues in the Activity field and hits the Reject button.
  • This changes the status of the story back to ‘Restart’
  • A developer should pick up the highest un-assigned story in a Restart state.
  • All Accepted stories are ready to be released and, ideally, should be released at the earliest opportunity.

Review

  • Stories should be reviewed against their stated goals after they have been released (this yet to be fully defined).

Iterate

  • Improvements should be developed from learnings gathered during planning, development and review.

This process is a little specific as we use the excellent Pivotal Tracker as our backlog management tool, however the process could be delivered using any Agile project management tool.

Leave a Comment