3 months ago I shared a few initial thoughts around standups and daily engineering activities and my thoughts have moved back to this exercise as we’ve continued to progress with our prototype and locking in on something that people really want.
And as I mentioned (and as many of you know) there are many different ways to go about doing a morning standup and the most important thing is that the team has a consistent time to discuss the project and the work that’s being done and that ultimately encourages dialogue and conversation to occur.
If those things are in place then you have the very fundamentals in place and it has all the opportunity to be a useful and beneficial block of time during the day.
Continue reading “A Better (Technical) Standup?”
We’re passionately curious about helping others build software better and as we continue to iterate on our prototype and concept we want to ensure that we’re answering the right questions and targeting the right problem areas as we build out our solution.
Naturally, at this early stage we have a lot of assumptions and a number of core hypotheses that we’re testing against and we fully admit that we don’t have a perfect idea of how all of these things will come across.
Continue reading “Survey: The Questions You Ask (While Building Software)”
If you’re subscribed to this blog (or follow on Twitter) then you may have noticed a small yet significant uptick on the posting here, moving from at least one blog post a week to two.
And, as many of you know, writing can take up a lot of time, even when the quality and output is somewhat mediocre and balancing the consistent practice and discipline of writing for a business blog with the work of business-building is really difficult.
And that’s not to taken lightly. Most business blogs, especially in the early stages, are completely bare if not altogether absent from the scene.
Continue reading “The Making of a Great (Developer) Blog”
If there’s one thing that is absolutely impossible to ignore it’s this: The rapid growth of mobile technology. It’s not just technology either – our entire way that we interact with it, the rest of the world, and especially with each other (e.g. relationships, communities). More people are experiencing the internet via mobile devices primarily than desktop. Full stop.
What’s probably most scary is that most of us have experienced this fundamental shift in our own adult lifetimes – we know what it’s like to spend 100% of our internet time on a desktop computer, and now, we’re spending much, much less.
Continue reading “On Developers and Mobile Native World”
I’ve been thinking about building out our customer and developer community as we start putting things together here and there’s so many exciting opportunities to do this really well (and a ton of great resources and how-tos) that can be used for modeling.
And, to a certain degree, there isn’t a right or wrong way to build a successful community around the product, assuming that you have the right ingredients to get things kicked off. Our team does has some significant experience building communities, developer-centric ones especially, but there are always newer tools to consider and ways to engage.
So, exactly how does one start?
Continue reading “Building a (Developer) Community from Scratch”
As I shared a few weeks ago, I put together a small working prototype for a news feed which was based on some of our original thoughts around a developer-centric feed and I promised that I’d share some of my work and the progress.
The motive for sharing this kind of stuff is quite simple: Providing an inside look at not just what we’re building but how and the why of our project is important because it keeps us honest and it enables us to get great feedback. And it’s just what I’m used to doing when I put new things together. I learn as much via the process of sharing as I do creating!
What I ended up doing was putting together a technical retrospective for myself and the team as to what I thought about it (so far) so as to give some useful context around the work itself and what I believed could be leveraged moving forward. It’s worth reviewing this post first to get some foundation of why I started and how I went about putting it together.
Hopefully you find this useful in your early-stage product / concept and prototyping work as you attempt to maximize the very limited amount of time that you have to build and get stuff done.
Continue reading “Retrospective: Building a Feed”
One of hardest things about putting together a new project is coming up with a suitable name. And, as I shared a while back, when I first starting blogging weekly about this project I mentioned, near the end, that it would be called “Pinpoint” until a better name came along or until we felt specifically inspired.
I even shared that, regardless of the name, that I really cared more about the brand as a whole (and perhaps a mascot of sorts) – we have all lived long enough to interface with companies and products that we love that have some of the strangest names to date.
Continue reading “What’s in a Name?”
A big part of putting together a new project is doing small, quick tests (e.g. iterations) around concepts that help you better grasp the overarching concepts and themes.
Said another way, building small, working prototypes can help you see more clearly the problem that you’re attacking and the possible solutions that could / might be deployed. And, if I’m to be honest, in many (most) cases it brings up more questions than answers.
But that’s kind of the point of the exercise, especially at the very early and concept stage: You have a hypothesis about X and you work quickly and efficiently to either prove it or disprove it and then rinse and repeat.
Continue reading “3 Principles on Building Experimental Prototypes”
Putting together a new project is both easy and hard, at the exact same time, especially from an engineering perspective.
I know that there are 1,000 things that I need to be doing, many of them at the same time, to get things moving in the right direction and yet I am also confident that I have the experience to move things forward and that if anything falls through the so-called cracks that they will be picked up over time.
This is because early stage product development is more of an experience than a process, more of an art than it is a science, and maintaining a certain level of joy in the work is just as important as building something that people (i.e. customers) actually, eventually, want.
And if you don’t like what you’re working on then there’s no point in building it in the first place, full stop.
Continue reading “Product Management at Early Stage”
I’m back in company-building mode, which means that my head naturally moves to more than just product and engineering. Putting the pieces together operationally is fun in all the right ways, even the more monotonous parts. This is mostly because I consider it an honor and a privilege to build something that people want.
In addition, I have this positive attitude because it means that we’ve landed on something that is resonating with folks. Not just myself and the team but also some of the financial backers that we’re beginning to have conversations and with, of course and most importantly, some of the early (future) users of the product.
Clearly we’ve hit a touch-point for both engineers and software development teams and the larger organizations that house them.
Continue reading “More Than Just Engineering”