Project Logs

Collapse

• Open for a Reason

  Bradley Gawthrop • 11/18/2019 at 17:30 • 0 comments

  Hey everybody! We're really humbled and gratified to have won the Hackaday Prize, and we're seeing a lot of interest on this project page! If you're thinking about hardware you might want to develop in the FieldKit ecosystem, especially sensors, I want to hear from you! We're not quite at the Arduino level of easy shield specifications and library support yet, but we're working on it, and we're keen to help out in the meantime. Drop us a line - bradley@conservify.org

• Making Lots

  Bradley Gawthrop • 09/30/2019 at 22:33 • 3 comments

  Outsourcing, Insourcing, and Open Sourcing.

  Our manufacturing philosophy is a little unorthodox, but in the interest of helping others who may have similar needs, I thought we'd talk about it a little.

  In the VC funded hardware startup world, there's a certain script, like the Hollywood three-act structure. You're meant to work your way through prototypes until you have a production-ready article,  and then send that off to China to have a gazillion made for cheap, and then presumably sell them to your gazillion customers and profit.  This consumer electronics model is typically taken as gospel. People emulate it because that's just what the "big kids" do. 

  But as the old saying goes, it ain't necessarily so. When I came to Conservify, my prior two EE related positions had involved not just design but profitably assembling all their own products in-house. This was a real education.

  When Conservify bought a pick and place, there was some slack-jawed bafflement and dismay on Twitter. Weren't we going to use contract manufacture? Well, of course we are, but not for everything, and not all the time. 

  When you have a simple product that gets sold to everybody in the same configuration, and you can reasonably anticipate the size of demand, and you have a lot of cash gently warming your pocket, outsourcing assembly can be the right call, but consider :

  FieldKit isn't a single board or product, it's an ecosystem. It is built from many different pieces that are meant to be put together in such a way as to fill a specific need. At the time of this writing, we have ten different boards working in the ecosystem, we have a list of desirable future modules and other additions which is that long again or longer.

  Conservify isn't a startup. We are a not-for-profit conservation laboratory. If we were to adopt a model where the only things we could make are things which would quickly pay back a production run of thousands, that would prevent us from solving important problems simply because the demand would not be great enough.

  Forecasting the future is difficult, but I suspect some of the most important and impactful projects we undertake will involve production quantities of hundreds or even dozens. Not every important problem carries iPhone level demand. 

  In the Open Source hardware world,  the high unit low margin products are also the ones most likely to be cloned by the unscrupulous.

  So I decided that we should be able to assemble everything we make in-house, without losing money. Even if not every product would generate eye-watering profits that way. This guarantees our freedom to explore new projects without enormous financial risks, or huge infusions of cash. It also means if we predict demand wrong, or a contract manufacturer screws up on delivery or quality, we can still fill our orders without losing our shirts. 

  So how does this influence the hardware design?

  No through-hole. In mass-manufacture, selective solder machines have made throwing a few through-hole components on a board easy. But in artisanal production, the soldering iron is where productivity goes to die. In the whole of the Fieldkit ecosystem of PCBs, there is only one through-hole component, and believe me, I'm still trying to figure out a way to bring that number to zero.

  No itty-bitty passives. We use 0603 throughout. Our pick and place could probably allow us to go a bit smaller, but yields would suffer, and rework is the enemy.

  One Side Only, Please. No big deal in mass manufacture to put SMD components on both sides of a board, but you pay heavy time penalties when you do it in-house. Doubling the number of passes through the production line has never yet proved worth it. All our boards are populated on just one side.

  Modest Panel Sizes. In-House assembly has a certain rhythm; you feed boards to the PnP, attend to any placements the machine can't deal with (tall stuff, in the case of our machine) and then into the...

  Read more »

• The journey to make FieldKit viable

  Shah Selbe • 09/30/2019 at 07:03 • 0 comments

  The origin story for FieldKit is similar to the origin story of many projects found on Hackaday.io. A few of us had an idea to do something better than was currently being done so we hacked something together. The first hardware was built on my dining room table, using a combination of Arduinos/Raspberry Pis, development boards, and easily obtainable sensors. The code was quickly taken over by Jacob, on a volunteer basis, to support some of those early tests in Botswana. Jer, and his team in NYC, worked on ways to visualize the data and make sense of it through storytelling. We were all helping a colleague, an ambitious scientist who was interested in trying a new way to do his work.

  Over the years the support and funding for FieldKit ebbed and flowed, mostly as a result of the field we work in. Conservation is not a discipline that traditionally accepted the benefits of technology development. Many of the tools that were in use came from repurposed technologies or ecology doctorate projects that spun off into companies. My initial research into conservation technology was part of a small body of work that has spent the better part of a decade trying to change that previous paradigm. It is how my relationship with the National Geographic Society first came to fruition, which ultimately (through folks that I met) resulted in the FieldKit project becoming an idea.

  I started Conservify as a mechanism to move that work forward. It is a technology development lab, not unlike others you see in places like Silicon Valley, but we are a nonprofit. All of the work produced at Conservify is completely open source. We also only work in the realm of wildlife conservation and environmental protection. This is important because that means the funding avenues we had for FieldKit are very different than the other commercial products that you might see documented on Hackaday. The lab is funded by philanthropic funding and research grants. That model makes product development very difficult to do, as most of that funding is tied to projects with a defined scope. 

  We interface with the open science hardware community (specifically GOSH - the Gathering of Open Science Hardware) and the researchers, companies, and nonprofits that frequent those circles. They face many of the same challenges we face in funding and building something sustainable (both financially and environmentally). But the mission behind open science is so fundamentally important, particularly when working with scientists in the global south. Science is underfunded in just about every country in this world, so the work to create better tools is critically important.

  Given that we are a nonprofit, our business model is different than a typical IoT company. We don’t (or more specifically, can’t) charge the same margins on our hardware that commercial entities do. We want people to use FieldKit regardless of whether they are using our hardware or not. Our aim is to engineer lower cost tools and create some easier mechanisms to increase the global capacity at scientifically relevant environmental monitoring. Sometimes that means that we are selling the devices and sometimes that means we are supporting the community in building off our work into something of their own. Given all of these considerations, our team has worked hard to develop FieldKit in the same way that an effective startup would develop their technology. We put the same considerations into user experience, design, and aesthetics that any commercial company would. Just because it is open source and nonprofit does not mean that it has to suck. 
  

  As a result, we have documented our costs pretty well. It is important for us to understand the fundraising ahead, so we can get sufficient grant funding to help and cover it. Above you see a small snapshot of our larger cost analysis, identifying the cost of goods sold for a part of FieldKit. Having “low cost” as a key...

  Read more »

• Testing for Wild Hardware

  Shah Selbe • 09/29/2019 at 19:58 • 0 comments

  One of the most important parts of the FieldKit project is thoroughly testing the hardware out in the field. The phrase “in the field” can mean many very different things to different projects. Often times, it means a production environment or out in the “real world” where it can interface with users and other systems. On some projects, this can be as easy as flipping a switch or taking a few steps out of an office. However for FieldKit, we quite literally mean the field.

  By design, our hardware is going to places that are not electronics-friendly. These are places that we have to worry about things like flooding, rats, biofouling, freezing temperatures, insect infestations, stolen solar panels, and anything else you can imagine could happen when you put unaccompanied electronics in the wild. On an earlier FieldKit iteration, we literally had a hyena chew up one of our sensor enclosures. We’ve had partners request that our sensors are built to be “elephant-proof” (a feat that, if you've ever seen an angry elephant, is nearly undoable). Anything is possible with enough money, but some things do not make sense for a product that is aiming to be low cost. 
  

  The more reasonable considerations have make their way into our design and we spend a lot of time prototyping and testing to make sure we can meet the needs of the users. Over the last year we have been testing prototypes in the Amazon Rainforest with the Tropical Rivers Lab at Florida International University. These have been absolutely instrumental at finding design issues, identifying bugs, and providing input into the UI of the app and website. Our partners here have been absolutely essential team members. All of those test units will be replaced by the production version of FieldKit in the next few months.

  The types of problems or UI/UX frustrations that come up when you are out in the middle of a field deployment are the things that you would never find during testing in the lab. There is a clear and undeniable benefit that comes from these experiences that makes them incredibly valuable. Over the next few months, we have a number of testing deployments planned to thoroughly vet FieldKit before its commercial release in the second quarter of 2020. Some of those will be local tests using the team at Conservify, including the deployment of some stations on the roof of the lab and in our respective backyards. Some of those will be with partners in other parts of the United States, including California, Montana, and Florida. Some of those will be across the globe, as we send production versions to some of the early adopters and advisors of FieldKit. All of the feedback and issues will come back into our issue tracking process at Conservify. We will incorporate the lessons learned into Jira to track any bugs or design flaws. This helps us prioritize the work moving forward. 

  The whole FieldKit team was recently in town for a design review. We decided it would be helpful to have everyone in the team do a test deployment of the FieldKit weather station. This included building up the station, using the app for deployment, letting it run for a bit, download the data off the hardware, and then disassemble the station. We arranged the teams so that the those doing software development and design, the folks who knew the app the best, would go last.

  The feedback from the team was everything we hoped to gain from an experience like that. We found software bugs within the app and how it interfaced with the hardware. We had improvements to the app UI and deployment process. We identified tweaks to the hardware to improve integration, the connector experience, and mounting. It allowed us to have a good evaluation of the effort required in the push to get us to that point. Even working to the dates of this field test allowed us to prioritize and push in areas to get us to a testable product.  

• Building a better box

  Shah Selbe • 09/28/2019 at 06:39 • 0 comments

  As with many electronics products, we started thinking about enclosures later than we probably should have. We had spent a lot of time thinking deeply about the design and style of the electronics, app, and website. Unfortunately, when it came to the case, we just made use of what was easiest. For much of its prototyping lifetime, FieldKit has made use of these commercially available ABS project enclosures that we would modify to incorporate things like buttons and cable glands.    

  There are plenty of benefits to using this COTS approach: 
  

  • Inexpensive unit cost and no upfront tooling or manufacturing budget impact
  • Easy to find online, even with next day shipping through Amazon
  • Modifiable if done carefully and correctly
  • Discrete and boring looking, which helps when installing electronics in places where you would rather not have people mess with them

  But this approach also leaves a huge amount to be desired. When compared to the amount of thinking that went into the design of the other parts of FieldKit, the act of putting the electronics in a box that looked like the one above felt uninspired. We had constant issues with the modifying of these boxes when adding cable glands, buttons, or adaptor plates. The worst part was the variability in the boxes, even when buying from a single supplier. They were different in color, consistency, hole patterns, and the plastic of the lid (transparent or opaque). They are fragile and crack easily. Finally, in my opinion, they are depressingly ugly and unimpressive. 

  Over the years, we have used a number of different off-the-shelf enclosures for our FieldKit (and other conservation technology) deployments. Some of the best to work with are the polypropylene copolymer protective cases like Pelican. They provide protection from impact, water, and allow for forgiving modification for cables and buttons. But they are expensive. So we started to take inspiration from those to think about what a custom-designed FieldKit enclosure would look like. 

  We wanted FieldKit to feel like it was at home in the wilderness, where much of this hardware was going, and like it was supposed to be a part of it. It needed to be rugged, deliberate, and inspire confidence in the user. We wanted it to be designed thoughtfully, both from an aesthetic feel (to go with the brand ideals we had with FieldKit) and a usability features perspective. We also wanted it to feel somewhat friendly, not intimidating, and not look like it was tactical hardware. There was a lot we were thinking about when developing the model. 
  

  So we started with the same mounting points as our previous COTS enclosure (both for standardization and to provide users options with what seemed to be somewhat standard in the junction box enclosure world) and build out some of the features we wanted. Our first prototype we had printed at Shapeways on an SLS printer to make sure we had the right tolerances and feel to the enclosure.

  This design had a few design elements that we were very excited about. It included a replaceable bottom plate that could be custom configured for the necessary cable glands, antennas, or bulkhead connectors for a specific sensor module configuration. This means means there is no custom drilling or modifications needed, just laser cut a plate that suits your needs and screw it in place. We had beefy mounting flanges that could accommodate a number of different attachment methods. The lid had a locking mechanism to keep away prying hands.
  

  After considerable testing, we realized that there were things that we needed to change. The gasket channels were not quite right. The clasps could be updated to accommodate more finger types and allow for better experience in opening and closing. We wanted to add a battery holder for commonly found 18650 battery packs, which had implications for the backplane board. We wanted more texture on the lid to differentiate it from just another a generic case. We also...

  Read more »

• Module Mayhem

  Bradley Gawthrop • 09/26/2019 at 16:50 • 0 comments

  So back in "Origin of Species" I talked about the big-picture hardware architecture of Darwin. Let's talk a little bit more about the architecture of modules, and why we made them the way we did.

  So what don't we want in FieldKit Modules?

  We don't want to have to manually configure each module. 
  Please, no jumpers, dip switches, or solder blobs to give them each a special address so as not to collide with another one.

  We don't want to have to tell Fieldkit everything.
  Like that a module has been inserted, or in what slot, or what kind of module it is. 

  We don't (typically) want to connect modules with cables. 
  They're bulky, fiddly in tight spaces, and don't provide physical support for the systems' hard-knock life.

  We don't want the module to be powered all the time.
  Batteries and Solar Panels are the most common way of powering FieldKit stations out in the world, so power consumption is always a concern. A module should come online at the selected interval,  take a measurement, and shut off. We can't rely on every future IC or sensor having effective power management on-board.

  This is a perfectly lovely set of aspirations, but several of them seem to be incompatible with using i2C, which is ubiquitous. 

  Enter Our Hero : Texas Instruments' TCA9548 - an i2C Multiplexer. This solves a lot of problems:

  Address Collisions.
  If each module is an address-space to itself, multiple identical modules can be connected and not collide. Cute, right?

  Module Identification.
  Since i2C address collision is no longer a thing, each one can have an EEPROM on a known address which contains information about itself, so Fieldkit can identify them in a slick and automatic way. Modules needing calibration can also carry calibration data on that EEPROM, which is nice if somebody, say, moves it from one slot to another, or from one station to another.

  Module Detection.
  Each 'client' side of the i2C multiplexer requires pullup resistors, like any other bus. If you put the pullups on the module, only slots with modules plugged into them will have a high SCL line with the bus at rest, which makes detecting the presence of modules easy.

  So what does our final bus look like?

  Power
  Modules are expected to do their own regulation and obey their Enable pins, so unregulated power and ground are provided. A regulated 3.3V line is also provided for the odd cases where some piece has to stay running even when the rest of the module is asleep. And Enable line is provided to turn the module on and off as required.

  EEPROM Protection
  A few modules require an onboard microcontroller. In these instances, the easiest way to pass data between modules and FieldKit is to stash it in the EEPROM we also use for module identification. This requires a negotiation line so you can prevent them from trampling all over each other. 

  i2C Bus
  Necessary and ubiquitous.

  SPI Bus
  This is mostly provided as a safety measure. We don't presently have any modules which require it, but it doesn't pay to assume we never will.

  Mechanical Considerations

  Modules have cables connected to them which might be heavy, and we don't want the leverage tearing headers off the boards, so while we use bog-standard 12-pin male box headers on the FieldKit side for their ubiquity and strength, we use a somewhat less common female header where the pins pass through the PCB via holes underneath the connector. This lowers the center of gravity and available leverage on the pins significantly.
  

  For belt-and-suspenders levels of resilience, we also have threaded standoffs on the backplane, with matching holes in the modules so they can be firmly secured in place. This seems excessive until the first time you drop one from a ladder.

• The FieldKit Portal

  Jacob Lewallen • 09/25/2019 at 15:29 • 0 comments

  Most of the development effort for FieldKit has been focused on the hardware, its firmware, and the app. There's another component in the platform that hasn't gotten much attention, because in the grand scheme of human undertakings it's Just Another Website. It's what we internally call the Portal.

  The portal is where users register and manage their accounts. It's got tools for administrative tasks and listing, monitoring and cataloging their FieldKit stations. It's reactive, but primarily meant to be consumed on a desktop because of the data visualization tools the portal provides for exploring the data streaming in from actively running FieldKit stations.

  Approaching the development of the portal was done like most of the other efforts. Even though it's the lowest priority, it's grown as we've needed functionality to support the most important user stories being developed in the mobile app and the firmware. Things like authentication, accepting data from the app and WiFi enabled stations, querying of that data and basic visualization support to allow the team to monitor the data coming from the early hardware. Regardless, we started wire-framing the portal early on, as you can see in these images. Once the User Experience is dialed in and mostly settled, our talented designer(s) start to add color and apply our style guide.

  From a technical perspective, the portal looks like any other modern site you're likely to see:

  • React/Vue. Work on the portal began several years ago and in the interim as our team as grown we've come to prefer VueJs for a number of reasons. Some political and some technical. Most of the administrative areas are React and will stay that way as long as their stable, but as new features and feedback from users comes in they'll be rewritten and brought up to date with the more modern sections.
  • Golang. Arguably an odd choice. Go is a great language though and while certainly prone to some verbosity it's very fast (and getting faster) and extremely readable and accessible. We have a lot of internal tooling that's also written in Go and having the easy ability to cross compile has been absolutely fantastic. For example we have several builds that produce binaries for darwin-amd64, linux-amd64 and linux-arm and being able to share tooling code with code that runs on the backend is very convenient.
  • PostgreSQL. An easy choice. PostgreSQL has been a favorite database of many team members for years and continues to get better. Plus, with access to several time series and PostGIS extensions this was the clear winner. It's also supported on RDS which, while more expensive, gives us some support we don't need to stress about as much day to day.
  • AWS. Probably one of the most controversial choices on the team. During our discussions about the company values we've talked at length about finding an alternative cloud provider that is more green and environmentally friendly. Unfortunately, our institutional knowledge and our use of Terraform for scripting the infrastructure meant we could be far more productive sticking with AWS in the near term.

  One technical note that some readers may find interesting is that architecturally there's actually two separate backend services. The first is monolithic and embodies what most people imagine as the backend. It implements the API, acting as the arbiter of state and business logic. The other, which we call the ingester, is extremely small and rarely modified. It's job is to accept data from stations and apps in the field and store them on S3. 

  One of the main reasons the portal is a lower priority is that it's the component with the fastest turnaround on development. Hardware has the longest cycle, followed by firmware and then the mobile app. Even though the mobile app is...

  Read more »

• User Testing Insights: How User-friendly is the Design?

  Lauren McElroy • 09/24/2019 at 18:10 • 0 comments

  An important and critical step in the UX Design process is User Testing. Before we moved too far in the design process, we conducted a usability test to determine if the app was an intuitive, valuable, and engaging user experience. 

  We recruited and tested with participants that were both non-technical "amateurs" and technically-minded "professionals" in environmental data collection. During the session, we gave participants tasks to complete using the mobile app prototype and hardware prototype. We measured the user testing with the following metrics:

  • Successful task completion: The percentage of task the participant completes
  • Errors: The number of errors that occur while completing the task 
  • Time to complete task: The amount of time it takes the user to complete a task
  • Task satisfaction: How the participant felt about the experience completing a task

  Key insights we learned from the user testing:

  • The FieldKit experience is a new paradigm for people who don’t have experience collecting environmental sensor data. The FieldKit experience and terms like “deployment”, “configuration” and “calibration” are not intuitive. The app needed more education and guidance for first time users
  • It was confusing to take the user to the station page before completing the setup process. The hardware setup needed a clearer onboarding experience that concluded with a visible state change upon completion of setup to clearly show that the station was ready to deploy. 
  • There was some confusion with the concept of “recording” at the completion of the deployment. We needed a clearer way to introduce the concept of recording data as part of the deployment process, and indicate clearly when the station was not recording versus recording 

  Key UX Enhancements

  • New app onboarding experience took the user through a more detailed setup showing images and on how to assemble and connect station
  • We created a set by step calibration guide for each module
  • A new design for the station page introducing the concept of recording data as part of the deployment process, and indicating clearly when the station was not recording versus recording

• Responsible environmental sensing

  Jer Thorp • 09/24/2019 at 14:36 • 0 comments

  Early on in the development of FieldKit, we had a meeting to discuss the project's goals, in as broad a sense as possible. We also wanted to look closely at what we thought were the project's values– the things that would define how the project existed as an entity in the real, human world. We ended up with five: Reliable, Legible, Open, Responsible, and Accessible. 

  Reliable means that FieldKit is not disposable tech. We want you to use our tools for years and decades. It also means that the data from FieldKit is certified to be accurate and scientifically valid.
  

  Legible means that data from FieldKit should be easily read and understood by anyone, not just people with science and math training. Likewise, our documentation and instructions should be readable by everyone (not just english language speakers)

  Open means that we release our hardware plans and software code, but also that we share our processes and plans, our philosophies and values. We open ourselves to collaboration and critique. 

  Responsible means that FieldKit products are built and shipped using environmentally responsible methods, and that we teach users how to deploy responsibly. It means that we have a plan for recycling our hardware. It also means that we take our users privacy and their data rights seriously.

  Accessible means that the entire project - hardware, software, community - is open to everyone. Specifically this means people who have historically been excluded from tech projects like FieldKit, including women, people of colour, LGBTQ+, the elderly, disabled people, and users from the global south. 

  As we've been building the three core parts of FK (the hardware, the software platform, and the community), we've tried to keep these five pillars of the project in clear view. With any step, small or large, we can ask ourselves how well we're fitting to these values. If a new interface feature seems really cool, but gets in the way of accessibility, we might revisit or even discard it. Same goes with hardware development– if there's a high environmental cost for a certain part or process we'll work to find better alternatives.

  Responsible is the value that I've thought the most about. I've been involved in tech for twenty years, and in that time have had a front row seat to the damage that (mostly) well-intentioned products have inflicted on our lives, and on the environment around us. Our political systems are being hacked, and our landfills are filling up with toxic waste in the form of discarded phones and tablets.

  In the last two years, I've become specifically aware of how much harm data systems have caused - from invasive ad-tech to facial recognition, the collection of data and its operationalization continues to put people and ecosystems at risk. We've become very good at envisioning the benefits of data collection, but not good at all at imaging its possible risks.

  In building FieldKit, we've focused on two paths toward data responsibility: mitigating potential harm and educating users. The former means building our data systems on secure protocols, and giving users control over how their data might be shared and to whom. The latter means asking questions about possible environmental and social harms of data collection before a FieldKit user heads out into the real world to deploy: 

  • Have you spoken to local wildlife experts to ensure your FieldKit station won't disrupt the ecosystem you're putting it in? 
  • What is your plan for retrieving and reusing/recycling your station? 
  • What indigenous territory are you deploying your station in and do they have rights to the data you're collecting under data sovereignty claims?
  • Are there local schools or community centers where you might bring the results from your station back to the people who live where you're collecting data from?
  • Are there other parties who might be interested in using this data? How do their interests differ from yours? Will making this data public cause...

  Read more »

• Technical Product Management with a distributed team; Or, Product Plate Spinning.

  Susan Alllen • 09/24/2019 at 01:55 • 0 comments

  Sometimes I refer to my job as “Chief Plate Spinner”. There’s something about the comical yet determined spectacle of spinning plates that feels like product management. FieldKit is certainly a technical cross-media product with multiple moving parts. With a lean team of 8 distributed across Los Angeles, Portland OR, New York and Connecticut, we strive to keep our particular plates spinning by continually building on good habits, optimizing workflows, and with a regular dose of face time.

  I’m a big fan of starting as you mean to go on. At project kick off, we took the time to set the tone as the whole team gathered in LA to align on FieldKit’s purpose, value and success criteria. Over the next two days, we hashed out our hopes and fears for the product, strategizing about team roles and risk management, and aligning on a clear shared vision.

  We tackled the big ticket items first, roughing out an overarching schedule for the year –  what the major moments might look like for hardware and software design and production, deployments, and community development. This long term forecast contained key milestones, a prioritized deliverables list, and a critical path for key work streams. This gave us a macro mechanism to monitor progress, anticipate upcoming time and resource crunches, and pivot as necessary. Much of a project like FieldKit is being able to set the ideal pace. Then knowing when to push to meet critical milestones, versus when to re-group and course correct.

  With those guideposts in place, we set up a regular rhythm of more detailed systems and processes that would support the work and facilitate the right kinds of conversations. That’s a fancy way of saying we put regular meetings in the calendar, set up an internal wiki with key product documentation and a task tracking system.

  The aim of the macro/micro approach was to facilitate productive communication, catch potential issues as early as possible and drive decision-making. We have a ton of ambition, even for a lean mean fighting team! So a concern was potential “analysis paralysis” and a lack of timely decision-making. While one remedy – the “Oh, sh*t!” method – was to visualize just how much we were trying to do and how little time we had left, another was to simply structure regular meetings less around discussions and notes, and more around decisions and actions.

  At the heart of the job is greasing the wheels to keep things moving. While sometimes that means pointing nervously to schedules and facilitating decisions, it also means entrusting your team with the expertise and responsibilities they have to deliver on the product vision. Especially with the highly technical aspects of electrical engineering, software programming, and 3D modelling needed to make FieldKit a reality. Other times that means leaning into lean – beyond job titles and technicalities – to hybrid moments that will get the job done. When we filmed the FieldKit prototype film, Lauren our product designer was the talent, I jumped in to help direct, and our product owner Shah was the director of photography!

  What remains crucial – especially for a remote team – is coming together for key in-person check-point meetings to not only hold each other accountable, but more importantly to build rapport, celebrate the wins, and galvanize our passion for the work. It’s a privilege to be working on such an important and optimistic product for the world with such a kick-ass team, and sometimes the best way to remember that is to raise a real life glass together!

View all 30 project logs