Leadership – Building Product Series (Part 2) – Nuance in definition

In part one we established that you don’t have a team that has the capabilities to build the product you want without input (and to fill in the blanks, let’s be honest you only specified broad strokes of what it is supposed to do).

And now you’re trying to be optimistic but you really have no idea how long this thing is going to take, and whether the team you have can pull it off. Deep breaths. Time to dig in.

At this point one should note that it’s critical that you establish unshakeable rapport with the team you’re trying to lead. If they don’t trust you enough to be honest, ask the right questions, or the wrong ones (If the latter, then you just received a strong signal your need to clarify or repeat yourself). You’re not going to be able to be effectively lead in the manner described throughout this series.

Now you’re going to take stock of what you’re working with, both of the technological process side and the relative strengths of the team members.

For the purposes of the examples that I’m going to write out in the examples below, I’m going to assume what I’ll call the classical setup. 1 Product Manager, 1 Designer, 1 Engineering Manager (Sometimes referred to as Tech Lead, especially if the developers don’t officially report to this person) 5 Developers (+- 2). Different variations could consist of a Quality individual, though sadly in my experience that’s not fashionable anymore, or a Project Manager, but those last two I’m going to omit since often teams don’t have them.

The first three I refer to as the triangle, because the relative strengths of the three are intertwined. A metaphor that might help explain relates to the term “Minimum Viable Product”, which gets thrown around a lot.

In order to get to that MVP I’d argue that you need a minimum viable talent of that triangle. You can have a stronger contributor in either of those three roles be able to make up in essence for less talented in the other roles, especially in this early phase of definition for the product.

For example, you’ve got an amazing Product Manager, has shipped numerous other complex product, maintained amazing relationships with everyone all over your organization, and my all metrics is one of those 10Xers or equivalent. You can then afford a less skilled Engineering Manager, and / or designer, and vice-versa.

All of this falls apart though, if the triangle can’t work together. If you don’t have that fit, your product will suffer, and may fall apart altogether.

Ok, that’s not the case, you have a competent triangle, they’re defining what your MVP is going to be, how long should that process take? Big question, a lot of other literature is going to say it depends, but I’m going give an actual number, no more than one month.

Why one month you might ask? If you can’t define what you’re building in one month, the actual build will likely take over a year, and when your project has a one-year birthday, it’s a failure. Now it might not be considered a failure to the company, but for the purposes of this blog series it is.

Entire companies rise and fall within a year, and you’ve only built this thing? What is the opportunity cost of whatever else you could’ve been building. Would you have taken on this project knowing it was a larger than one year endeavor?

Now what does the definition phase of a product actually look like? What is the deliverable? The actual thing you’re trying to build will of course vary greatly depending on you business, but the actual output should be roughly the same.

By the end of this phase, you’re trying to gather as much information as you can, and have a strong vision of what to build and why. You should be able to explain to team members and stakeholders, in varying levels of detail, tailored to the audience what your product does. Who is the target audience, what is the TAM (Total Addressable Market) if it’s a business, and what success looks like.

The what might be a feature on a established consumer facing website / app, it might be a new one idea, it might be a pivot, it might be a tool to facilitate some business process. Whatever the case may be, you’re going to need to be able to articulate and defend why this product at the expense of any other potential product.

The why usually takes the form of why some party will benefit once the existence of this software happens. One of my favorite game changers, from years back, in the world of software was Google Maps. It largely ushered in the modern “slippy” map, and also showed the world the power of partial refreshing of the document. Move or zoom the map, more map appeared. Clear benefit for all consumers even in the most raw form. Enter an address and instantly see what’s nearby, zoom out and get a broader viewpoint. Past the MVP it became a platform that expanded into turn by turn directions once Mobile became a thing. Once telemetry was fed back into it, you got live traffic, which changed the world.

In the case above, the benefitted party was, more or less, everyone. Obviously most things will have a narrower scope, so let’s go to the other side of the spectrum. When you build some business that has users, there will inevitably be things you didn’t account for and hopefully you have some way for customers to have their problems fixed. A typical solution for this will be a customer service team. You need to build tools for these team members to self-serve. Otherwise your engineering team will get inundated with common “operational” problems, and won’t be able to build wholistic solutions. So the why you might be building those tools that you just found a need for is to enable your customer service team and free up your engineers.

Output. What are the artifacts created to show you have enough definition to proceed? Some sort of “central document” will exist, potentially a product brief, potentially a wiki document with links to the various engineering tickets your product manager creates, and potentially a design wireframe is about what to expect at this point. I’ve also seen a powerpoint deck created, and that be passed around after a meeting where the output of the definition phase is shared.

One note, you want to make sure that if there are going to be common points consistently arising on the product you’re building, it would make sense to call those out in those output documents, so you don’t have to repeat that conversation.

Leadership – Building Product Series (Part 1) – Software Teams

Team built software is much more of an art than anyone gives it credit for. Much of the written information around the process assumes that you’ll be able to figure out a magic formulae that will result in a repeatable process. After years in developing software as an IC (Individual Contributor), learning the different disciplines (Product Management, UI/UX) enough so I can effectively lead, I’ve come to believe it’s the sum of the individuals within the building, and through this series we’ll look at a number of the components that will end in success or failure.

Talent. If you have that, the rest is just window dressing. Organizations sometimes don’t spend much energy defining process and have results, how can that be? Don’t you need a Scrum Master and need to follow the Agile Principles. Or perhaps we need to spend a year writing the perfect requirements (Waterfall)?

There’s a category in the Situational Leadership Model called S4.

Another term that get’s thrown to describe these individuals around is 10X or 10Xer. The gist of this type of talented person doesn’t really need to be given much more than a clear set of requirements and if you have a team full of this type of people, you really just need to explain what you want. A few caveats, it may be possible but early career employees no matter the raw talent, aren’t going to likely be able to do this, because they simply don’t know enough of the pitfalls to avoid falling into one. The minimum I’ve seen here is around 3 years full-time development.

Ok, so you aren’t given, or haven’t created, a team of fully self-sufficient team members, now what? This is where really the job of the leader becomes more important. If you can get the product you want out is going to require you finding the balance point between providing a place where the learning and creativity can happen and grinding out the product you need at the end of the day.

How to create a MacOS (Cocoa) App in Rust (Part 1)

There is surprisingly little information on how to actually build something of use in Cocoa with Rust. I worked my way through it with a lot of perseverance so hopefully I can save you, dear reader some of the frustration along the way. At the end of this Part 1 you’ll have a running app with a button that executes a block of code.

First, a bit of the state of the union that I’ve found. There is an ongoing project to wrap some of the Appkit and Foundation libraries going on over at the Mozilla sponsored Servo project. Specifically, Core Foundation RS. I’ve added a few small PRs to that. That project builds upon the work done by Steven Sheldon’s Rust-Objc

Ok, let’s get started. As with most things Rust, you’re going to need to to add the relevant dependancies to your Cargo.toml as of this publication

"cocoa" = "0.19.1"
"core-graphics" = "0.17.3"
objc = "0.2.3"

From here let’s copy / paste the hello world example

extern crate cocoa;

use cocoa::base::{selector, nil, NO};
use cocoa::foundation::{NSRect, NSPoint, NSSize, NSAutoreleasePool, NSProcessInfo,
use cocoa::appkit::{NSApp, NSApplication, NSApplicationActivationPolicyRegular, NSWindow,
                    NSBackingStoreBuffered, NSMenu, NSMenuItem, NSWindowStyleMask,
                    NSRunningApplication, NSApplicationActivateIgnoringOtherApps};

fn main() {
    unsafe {
        let _pool = NSAutoreleasePool::new(nil);

        let app = NSApp();

        // create Menu Bar
        let menubar = NSMenu::new(nil).autorelease();
        let app_menu_item = NSMenuItem::new(nil).autorelease();

        // create Application menu
        let app_menu = NSMenu::new(nil).autorelease();
        let quit_prefix = NSString::alloc(nil).init_str("Quit ");
        let quit_title =
        let quit_action = selector("terminate:");
        let quit_key = NSString::alloc(nil).init_str("q");
        let quit_item = NSMenuItem::alloc(nil)
            .initWithTitle_action_keyEquivalent_(quit_title, quit_action, quit_key)

        // create Window
        let window = NSWindow::alloc(nil)
            .initWithContentRect_styleMask_backing_defer_(NSRect::new(NSPoint::new(0., 0.),
                                                                      NSSize::new(200., 200.)),
        window.cascadeTopLeftFromPoint_(NSPoint::new(20., 20.));
        let title = NSString::alloc(nil).init_str("Hello World!");
        let current_app = NSRunningApplication::currentApplication(nil);

Give it a go with

cargo run --release

Alright if that worked you should see something similar to this…

Classic Hello World

For me, that was amazing, no Xcode and we have an app up on OSX, my mind started imagining with the possibilities.

Ok, so to wrap up this tutorial we’re going to create a button that has an action and a target, simple right. Well, in short no. We need to dynamically create all the classes on the OBJ-C side, since we’re going to be mostly just passing messages.

First off, we’re going to create a custom class so that we can place code, objc-rust provides this functionality. Warning though we’re going to be running all unsafe code, as usage of raw pointers is the name of the game.

use objc::declare::ClassDecl;
extern crate objc;

    fn register_button() {
        unsafe {
            let superclass = class!(NSButton);
            let mut decl = ClassDecl::new("HelloWorldButton", superclass).unwrap();

            extern fn clicked(_this: &Object, _cmd: Sel) {
                unsafe {
                    println!("clicked {:?}", _this);

                     let alert:*const Object = msg_send!(class!(NSAlert), alloc);
                     let alert:*const Object = msg_send!(alert, init);

                     let alert_title = NSString::alloc(nil).init_str(&"Hello World".to_string()).autorelease();
                     let alert_body = NSString::alloc(nil).init_str(&"You Clicked Me!").autorelease();

                     let _alert_id: id = msg_send!(alert, setMessageText:alert_title);
                     let _alert_id: id = msg_send!(alert, setInformativeText:alert_body);
                     let _alert_id: id = msg_send!(alert, runModal);

            let clicked: extern fn(&Object, Sel) = clicked;
            decl.add_method(sel!(clicked), clicked);

Ok, there’s a lot going on there, so let’s break it down. First we’re adding some imports into the file, for the lower level rust-objc dance we’re going to do. Now into the register_button fn. As I referenced before, there’s the unsafe block, get used to those.

Our first bit of interaction with objc starts here. The class! macro instantiates a class of the referenced name, objc must already have that declared, and in this case, it does as part of the standard library, NSButton.

Now some magic here, we’re going to dynamically create a custom class that we can instantiate ourselves later. We’re calling that HelloWorldButton and it’s a descendant of NSButton.

Now that we have a dynamic class let’s add some structure to it, below we declare the external fn that is to be called later, which will cause the below alert.

You clicked me!
       fn create_button(frame: NSRect, title:String) -> *mut Object {
        unsafe {

            let button: *const Object = msg_send![class!(HelloWorldButton), alloc];
            let button_with_frame: *mut Object = msg_send![button, initWithFrame:frame];
            let title_as_nsstring = NSString::alloc(nil).init_str(&title.to_string()).autorelease();
            let _title_return: id  = msg_send![button_with_frame, setTitle:title_as_nsstring];
            let _hello_world_button_msg: id = msg_send![button_with_frame, setTarget:button_with_frame];
            let _hello_world_button_msg: id = msg_send![button_with_frame, setAction:sel!(clicked)];

This block is hopefully a bit more straightforward, notice the re-use of HelloWorldButton which we registered above, we create the button & add the title. One tricky thing to remember is you need to create an objc string. Finally we’re going to direct objc to point the target and action of the click, this took me a long time to figure out, hopefully this will save someone hours of frustration. the sel! macro is interesting, once you have declared something on a native or custom class, it behaves the same a objc with unlimited parameters separated by “:” tokens.

Finally, let’s put it altogether.


let hello_world_button_frame:NSRect = NSRect::new(NSPoint::new( 0., 30.), NSSize::new(20., 10.));
let hello_world_button = create_button(hello_world_button_frame, "Click Me".to_string());

We call the functions we created earlier to register and create, and while this won’t work for a larger app we’re just going to make the button be the contentView for the window at this point. NSButton derives at some point from NSView so it’s all good.

Innovation Back to Back Winner

I’m gushing a bit.

While the prizes may not be a investing by Ron Conway, or 50k cash, it is nice to feel that my peers think what I contributed to is worthwhile.

Can’t go into details about what the projects are, but hopefully they’ll end up on the companies’ roadmap.

If you don’t know Trulia, it’s the best Multi-Market real estate site.

Check out listing for San Francisco.


New Plugin – EasyShipper

Spent some time over the last month building out an integration for WooCommerce & Easypost, since I liked their product. I am pretty happy with the outcome, looking to get some feedback from users once posted over on the directory. Seems to be going well already have 30+ downloads in one day.

I toyed with the idea of selling it commercially, in the end I am open sourcing it. I think both of these products are of the highest caliber.

Have a look at EasyPost at https://www.easypost.com/.

Check the plugin it out on GitHub or WordPress